Hi all,
I have one dev-point regarding ContentBuffer. We try to minimize allocation rate and prefer bigger buffers to avoid their expension in case of bigger messages. It looks like the reset() function does not take into account the initial buffer size and works with the hardcoded value 4096bytes.
com.solacesystems.jcsmp.impl.ContentBuffer#DEFAULT_SZ
Would it be possible to change the behavior to respect the provided initial size?
Thanks a lot,
Petr
Hello Petr,
Can you provide more details on how your a setting a ‘provided initial size’. ContentBuffer and DEFAULT_SZ are not part of the JCSMP exposed API. As a producer of messages, the application is entirely in control of the message size and backing buffers, so this parameter is not relevant.
Are you trying to control how buffers are allocated for receive? What size messages do you expect to receive on average?
There are some optimizations to avoid excessive reset() in the works already, but currently no plans to make it configurable. If we understood your use case better, we can consider it for a future release.
Thanks,
Ragnar
Hello Ragnar,
Thanks for you answer. Understood, I’ll go deeper into the detail.
First, I’m fully aware of using internal API (in the package “impl”) and it’s up to me to take a risk of changing the public methods 
My use-case: to avoid the allocation of buffers I created/cached in Thread-Local CustomJCSMPXMLMessage.
Next I create our ContentBufferOutputStream:
And then (removed details for the sake of simplicity):
Very often we have 1MB message, 4MB in the extreme cases (in these cases I am OK with recreating the buffer in the reset message). 1MB buffer would cover all our cases, recreated 4kB buffer is unfortunately too small.
Before and after the changes can be seen here (it’s AsyncProfiler allocation flamegraph - it’s based on JFR TLABs sampling), the purple color is HeapByteBuffer. :
In the most of out applications we went don’t from 20-25% allocation rate to 5-10%. With setting the size of internal buffer to the original initial size (when the JCSMP message is created) we would eliminate the allocation of HeapByteBuffers completely.
I know it’s an internal API and you keep it this way, but it would be very helpful
Thanks and regards,
Petr
Thanks Petr,
We are aware of the excessive reallocations in JCSMP whenever a message is reset. The default size of 4096 is a hold-over from ancient days and is an arbitrarily small number in the modern world. We already have in development an API that only resets when the allocated buffer exceeds 100K.
However based on your feedback, we’re re-evaluating even that. We’ll look at this more in January, with an eye to eliminating buffer reallocations or making it configurable. TBD. But we will be addressing this in the first quarter of 2024.
Regards,
Ragnar
Hi Ragnar,
thanks for taking my case into your consideration. Please, let me know if you need any assistance or testing.
In any case, wish all of you at Solace a Merry Christmas and a Happy New Year
Best regards,
Petr
