argus/radium problem

[Carter Bullard]

Hey CS Lee,
Just going through the messages you sent, so we have some dialog on what is going on.

All of these particular messages are ok.  Your processing some UDT traffic on one thread, that would
be the ArgusModeler thread, and then we jump to another of argus's threads, the Output process thread, where
we are taking flow records off the scheduler queue, and finding remote clients to write the records to.
You can see which thread, as the second hex number after the pid in the log entry.

Format is " argus[pid.thread] date routine(parameters) message.

At first there are no clients, and then one shows up, we send the argus management record to it (128 bytes),
and then we wait for the client to send the "START" indicator, which in this slice doesn't happen, so
records are coming in, client is pending, but not ready, and we drop the records.  All of these messages
are correct.

Carter

On Jun 7, 2012, at 10:12 PM, CS Lee wrote:

> hi Carter,
> 
> I don't know if bivio team has compiled it with threaded support, need to ask them(joel in bivio) if you know him. 
> 
> Here's the argus output message when radium connects to it -
> 
> ArgusUpdateUDTState(0x49dd65a8, 32) UDT_DATA_PACKET seq 0x32a5da00 msgnum 0x66573422 tstmp 0x216c794 sockid 0x12ce55c8 loss 0
> argus[27125.498dd490]: 08 Jun 12 08:26:57.178068 ArgusUpdateUDTState(0x49dd65a8, 32) UDT_DATA_PACKET seq 0x329ee15a msgnum 0x31573422 tstmp 0x216c794 sockid 0x12ce55c8 loss 0
> argus[27125.498dd490]: 08 Jun 12 08:26:57.196113 ArgusUpdateUDTState(0x49dd65a8, 32) UDT_DATA_PACKET seq 0x321c61e1 msgnum 0xac573422 tstmp 0x216c794 sockid 0x12ce55c8 loss 0
> argus[27125.498dd490]: 08 Jun 12 08:26:57.220138 ArgusUpdateUDTState(0x49dd65a8, 32) UDT_DATA_PACKET seq 0x3227377b msgnum 0xba573422 tstmp 0x216c794 sockid 0x12ce55c8 loss 0
> argus[27125.498dd490]: 08 Jun 12 08:26:57.293605 ArgusUpdateUDTState(0x49dd65a8, 32) UDT_DATA_PACKET seq 0x32ac4271 msgnum 0x59573422 tstmp 0x216c794 sockid 0x12ce55c8 loss 0
> argus[27125.48c93490]: 08 Jun 12 08:26:58.039943 ArgusLoadList (0x1009b9c0, 0x1009b948) load 1 objects
> argus[27125.48c93490]: 08 Jun 12 08:26:58.040039 ArgusFreeListRecord (0x100f679c) returning
> argus[27125.48c93490]: 08 Jun 12 08:26:59.243664 ArgusLoadList (0x1009b9c0, 0x1009b948) load 1 objects
> argus[27125.48c93490]: 08 Jun 12 08:26:59.243759 ArgusFreeListRecord (0x100f6b44) returning
> argus[27125.48c93490]: 08 Jun 12 08:26:59.413949 ArgusLoadList (0x1009b9c0, 0x1009b948) load 1 objects
> argus[27125.48c93490]: 08 Jun 12 08:26:59.414030 ArgusFreeListRecord (0x100f6eec) returning
> argus[27125.48c93490]: 08 Jun 12 08:26:59.767378 ArgusLoadList (0x1009b9c0, 0x1009b948) load 1 objects
> argus[27125.48c93490]: 08 Jun 12 08:26:59.767474 ArgusFreeListRecord (0x100f7294) returning
> argus[27125.48c93490]: 08 Jun 12 08:27:00.112948 ArgusLoadList (0x1009b9c0, 0x1009b948) load 1 objects
> argus[27125.48c93490]: 08 Jun 12 08:27:00.113028 ArgusFreeListRecord (0x100f763c) returning
> 
> Then after a while, this appears -
> 
> ArgusGenerateInitialMar() returning
> argus[27125.48c93490]: 08 Jun 12 08:27:09.083154 ArgusCheckClientStatus: wrote 128 bytes to client
> argus[27125.48c93490]: 08 Jun 12 08:27:09.083175 ArgusCheckClientStatus() returning
> argus[27125.48c93490]: 08 Jun 12 08:27:09.083192 ArgusLoadList (0x1009b9c0, 0x1009b948) load 19823 objects
> argus[27125.48c93490]: 08 Jun 12 08:27:09.083209 ArgusOutputProcess() 1 client(s) for record 0x4ce4e2a4
> argus[27125.48c93490]: 08 Jun 12 08:27:09.083226 ArgusOutputProcess() 1 client(s) not ready fd 4 sock 0x4f500008 start 0
> argus[27125.48c93490]: 08 Jun 12 08:27:09.083244 ArgusFreeListRecord (0x4ce4e2a4) returning
> argus[27125.48c93490]: 08 Jun 12 08:27:09.083260 ArgusOutputProcess() 1 client(s) for record 0x4ce4e64c
> argus[27125.48c93490]: 08 Jun 12 08:27:09.083276 ArgusOutputProcess() 1 client(s) not ready fd 4 sock 0x4f500008 start 0
> argus[27125.48c93490]: 08 Jun 12 08:27:09.083293 ArgusFreeListRecord (0x4ce4e64c) returning
> argus[27125.48c93490]: 08 Jun 12 08:27:09.083310 ArgusOutputProcess() 1 client(s) for record 0x4ce4e9f4
> argus[27125.48c93490]: 08 Jun 12 08:27:09.083326 ArgusOutputProcess() 1 client(s) not ready fd 4 sock 0x4f500008 start 0
> 
> 
> On Fri, Jun 8, 2012 at 10:02 AM, Carter Bullard <carter at qosient.com> wrote:
> Well, if it's getting write errors we should be shutting down the connection and deallocating any queued records.  This is useful.  Let me see what I can do with this.
> 
> Carter
> 
> Sent from my iPad
> 
> 
> -- 
> Best Regards,
> 
> CS Lee<geek00L[at]gmail.com>
> 
> http://geek00l.blogspot.com
> http://defcraft.net

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20120608/d2f5f8c3/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4367 bytes
Desc: not available
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20120608/d2f5f8c3/attachment.bin>