Opaque message size limitations
What factors influence the maximum size of an opaque message that can sucessfully pass through the TREP platform?
Using infrastructure ADS/ADH v3.0.2 and client UPA/ETA v3.0.0.L1. I was able to sustainably publish and subscribe to 256kb objects, but things ground to a halt witha 4mb object and things had to be restarted to recover e.g. in the ADS log file "Suspended requests due to transport congestion."
I appreciate that pushing large quantities of raw data through the platform probably isn't going to be particularly efficient and there may well be likely more suitable solutions, but I am interested in the realistic capabilities and limitations of using TREP for passing opaque binary objects around.
So right now the max message size is 64k across the backbone. It does sometime work with larger messages but we've found some issues with the code recently that prevents this from working 100% of the time.
In addition, you would need to set the *numBuffers : 10000 or something much higher than the default of 190. This is the main reason ADS might lock up if sending large messages as it will run out of buffers attempting to reassemble.
We have been working on resolving this limitation and hope to get this fixed in a subsequent release.
You may try to increase the number of output buffers in ADS.
*ads*maxOutputBuffers *ads*guaranteedOutputBuffers *ads*poolSize
The buffer size of RSSL is 6144 bytes and the default value of guaranteedOutputBuffers is 200. Therefore, its size is 6144 * 200 = 1,228,800 bytes which is less than 4MB object.