TCP Buffer(s)

[GaryGalbraith]

I'm currently trying to sort out a TCP input issue I'm having with the 'TCP Stream Control' and the 'TCP In Watcher - Text' actors. I noticed that the 'TCP In Watcher - Text' has a buffer input now which is not documented in the manual.  (I am assuming that the actor was updated at one point since the image of the actor does not match what the actor looks like.)  The online help simply says that this is the buffer size (up to 256 MB).

Can someone help me understand the 'relationship' between the buffer in the TCP Stream Control and the buffer in the 'TCP In Watcher - Text'?  Are they the same - meaning that they use the same buffer?  Or, do they both have independent buffers?  

Would best practices suggest that both buffer sizes be the same?

[DusX]

@garygalbraith

Unfortunately, I do not know for certain, but since they are set separately I believe these are separate buffers

@mark will need to provide more detail.

Certainly, you don't need a 256mb buffer for anything I can think of, and keeping buffer sizes small will be faster. 
What types of values are you receiving?

[GaryGalbraith]

@dusx - The patch is receiving JSON in variables size packets.  Izzy will sometimes crash when the data stream is activated and I have started a separate thread on that issue.  My investigating the actors led me to question the possibly play between the buffers of the different actors - hence my initial question.

Currently I have the buffers on both the 'TCP Stream Control' and the 'TCP In Watcher - Text' set to 8K which I would think would easily hold one complete JSON data object that feeder systems sends.  Does this rationale make sense?

I await additional clarification from Mark (@mark) regarding the different buffers when he can.

[DusX]

@garygalbraith said:

set to 8K which I would think would easily hold one complete JSON data object

 Likely this is enough.. I don't know the size of these JSON objects. Try saving the largest JSON data into a TXT file and look at the size of the file. That should give you a clear idea about what memory is required per message.

What are you using as the string parsing pattern in the TCP in Watcher - Text?

[GaryGalbraith]

@dusx - Agreed!  8K should be ample for the particular data stream.  The pattern I'm using in the 'TCP In Watcher - Text" is 'data:string={00-FF}' (without the single quotes)

[DusX]

@garygalbraith said:

data:string={00-FF}

 Well that really shouldn't cause any trouble. I will see if I can set up some type of Tcpip testing config and reproduce your issue.