CMessagePipe - say what?

jjames

Does anyone know what the "CMessagePipe::Max = " is? I've seen this before, and I believe was a warning sign to when a system I had locked up before. Or maybe it locked for for another reason - though I never saw that message again when I fixed some code. Perhaps it's nothing . . . maybe not. I can't find anything on it in TechNotes nor on the forum.

Here's a snipped from my startup in diagnostics, note lines 3,4,5,21 and 31.

Any help is appreciated.

--------------------------------------------------------------------------------------------------------------------------------
    1: 12-02-2005 FRI 10:20:31 ConnectionManager      Memory Available = 24913092 <10456>
    2: 12-02-2005 FRI 10:20:31 ConnectionManager      Memory Available = 24923548 <12128>
    3: 12-02-2005 FRI 10:20:28 Unknown                (Reader=tInterpreter writer=tDeviceMgr)- CMessagePipe::Max = 100
    4: 12-02-2005 FRI 10:20:28 Unknown                (Reader=tInterpreter writer=tDeviceMgr)- CMessagePipe::Max = 75
    5: 12-02-2005 FRI 10:20:28 Unknown                (Reader=tInterpreter writer=tDeviceMgr)- CMessagePipe::Max = 50
    6: 12-02-2005 FRI 10:20:25 Interpreter            CIpEvent::OffLine 0:5:1
    7: 12-02-2005 FRI 10:20:25 Interpreter            Exiting TCP Read thread - closing this socket for local port 5
    8: 12-02-2005 FRI 10:20:24 Interpreter            CIpEvent::OnLine 0:5:1
    9: 12-02-2005 FRI 10:20:24 SocketManager          Connected Successfully
   10: 12-02-2005 FRI 10:20:23 Interpreter            CIpEvent::OffLine 0:5:1
   11: 12-02-2005 FRI 10:20:23 Interpreter            Exiting TCP Read thread - closing this socket for local port 5
   12: 12-02-2005 FRI 10:20:22 Interpreter            CIpEvent::OnLine 0:5:1
   13: 12-02-2005 FRI 10:20:22 SocketManager          Connected Successfully
   14: 12-02-2005 FRI 10:20:21 ConnectionManager      Memory Available = 24935676 <21176>
   15: 12-02-2005 FRI 10:20:20 ConnectionManager      Memory Available = 24956852 <10304>
   16: 12-02-2005 FRI 10:20:19 ConnectionManager      Memory Available = 24967156 <38808>
   17: 12-02-2005 FRI 10:20:18 Interpreter            CIpEvent::OnLine 5001:17:1
   18: 12-02-2005 FRI 10:20:18 Interpreter            CIpEvent::OnLine 5001:16:1
   19: 12-02-2005 FRI 10:20:18 Interpreter            CIpEvent::OnLine 5001:15:1
   20: 12-02-2005 FRI 10:20:18 Interpreter            CIpEvent::OnLine 5001:14:1
   21: 12-02-2005 FRI 10:20:18 Unknown                (Reader=tCypherConnRx writer=tConnectMgr)- CMessagePipe::Max = 50
   22: 12-02-2005 FRI 10:20:18 ConnectionManager      Memory Available = 25005964 <10592>
   23: 12-02-2005 FRI 10:20:18 Interpreter            CIpEvent::OnLine 5001:13:1
   24: 12-02-2005 FRI 10:20:18 Interpreter            CIpEvent::OnLine 5001:12:1
   25: 12-02-2005 FRI 10:20:18 Interpreter            CIpEvent::OnLine 5001:11:1
   26: 12-02-2005 FRI 10:20:18 Interpreter            CIpEvent::OnLine 5001:10:1
   27: 12-02-2005 FRI 10:20:18 Interpreter            CIpEvent::OnLine 5001:9:1
   28: 12-02-2005 FRI 10:20:18 Interpreter            CIpEvent::OnLine 5001:8:1
   29: 12-02-2005 FRI 10:20:18 Interpreter            CIpEvent::OnLine 5001:7:1
   30: 12-02-2005 FRI 10:20:18 Interpreter            CIpEvent::OnLine 5001:6:1
   31: 12-02-2005 FRI 10:20:18 Unknown                (Reader=tCypherConnRx writer=tConnectMgr)- CMessagePipe::Max = 25
   32: 12-02-2005 FRI 10:20:18 Interpreter            CIpEvent::OnLine 5001:5:1
   33: 12-02-2005 FRI 10:20:18 Interpreter            CIpEvent::OnLine 5001:4:1
   34: 12-02-2005 FRI 10:20:18 Interpreter            CIpEvent::OnLine 5001:3:1
   35: 12-02-2005 FRI 10:20:18 Interpreter            CIpEvent::OnLine 5001:2:1
   36: 12-02-2005 FRI 10:20:18 Interpreter            CIpEvent::OnLine 5001:1:1

DHawthorne

It's the internal message queue the master uses to communicate with devices. On large systems, it's critical to keep this queue from backing up too much, it will take the system down if it overflows and the messages keep coming in. The Queue_and_Thresholds.axi file will help to optimize the queue for larger systems, but you still need to make sure you aren't flooding your system with updates and feedback messages. My rules of thumb: only send data that has changed, test for the change first; only send to pages that are actually displayed; put feedback in a 1 second repeating timeline rather than mainline.

The Max: value, near as I can figure, is the number of messages backed up when the notification was generated (it's not really an error until you get the notification that the queue overflowed).