On 17/01/2022 15:24, Jonathan Valliere wrote:
Emmanuel, The socket receive side buffer is stored for as long as necessary. You are referring to the clear-text application buffer here https://github.com/apache/mina/blob/660ab2375b4b47b5ebe86226c92f3138be4c96e8/mina-core/src/main/java/org/apache/mina/filter/ssl/SSLHandler.java#L277 It would be possible to cache this in a Thread-Local-style however, not all SSL sessions have the same parameters so you risk necessary expansions;
I was thinking that we could use a big enough buffer to fit all the needs (like 32kb), assuming the compression method is always NULL, but it may not be the case, so yeah, it might not be such a good idea.
additionally you would have to permanently remove that buffer from Thread-Local once anything is written into it for safety of the user-application. Have to be very careful not to maintain any pointers once that or a section of that buffer has been passed onto the next downstream filter.
Indeed. Zeroing the buffer after each usage probably makes the gain of having a unique buffer pretty null.
All in all, allocating 16Kb of data is quite fast in modern JVM, and even if it has to be zeroed, it won't remain in memory for a long time.
Doesn't IoBuffer have a built-in caching mechanism?
Not by default. We use a SimpleBufforAllocator. Although there is a CachedBufferAllocator, it's not use anywhere.
free() is called when
its no longer needed which should make it fully compatible https://github.com/apache/mina/blob/660ab2375b4b47b5ebe86226c92f3138be4c96e8/mina-core/src/main/java/org/apache/mina/filter/ssl/SSLHandlerG0.java#L201 There is some room for improvements on decoding as many messages as possible on the receive side before looping. I will think about that.
Ok, thanks ! -- Emmanuel Lécharny --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
