🎄 Happy Holidays! 🥳
Most of Solace is closed December 24–January 1 so our employees can spend time with their families. We will re-open Thursday, January 2, 2024. Please expect slower response times during this period and open a support ticket for anything needing immediate assistance.
Happy Holidays!
Please note: most of Solace is closed December 25–January 2, and will re-open Tuesday, January 3, 2023.
Resetting ContentBuffer to its initial size
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
Comments
-
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
0 -
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.<init>:
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,
Petr0 -
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
0