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; 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. Doesn't IoBuffer have a built-in caching mechanism? 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. On Mon, Jan 17, 2022 at 1:30 AM Emmanuel Lécharny <[email protected]> wrote: > > > On 14/01/2022 14:46, Jonathan Valliere wrote: > > > https://github.com/apache/mina/blob/c0ee516726c21115b196834ee984be786cea5818/mina-core/src/main/java/org/apache/mina/filter/ssl/SSLHandler.java#L277 > > > > in 2.2.X the decode buffer is automatically calculated based on the input > > size so the entire input buffer can be decoded. These buffers cannot be > > cached anywhere like Thread-Local because the decoded buffer must be > > cleanly passed onto the next filter which may or may not go asynchronous. > > > Hi Jonathan, > > when we receive data, we first allocate a 2048 buffer (default size, can > be changed with config), read the data and propagate it to the chain. > > The Sslhandler first step is to allocate a big (16Kb) buffer before > calling SslEngine.unwrap(). > > This is where I think it might make sense to use a TLS stored buffer: > - we reuse it in SslHandler for the app buffer > - if unwrap does not have any byte produced (HS), then we can simply > reset the buffer > - otherwise we can now allocate the proper buffer (which is likely to be > way smaller) to fit the clear text data into it, instead of passing the > big allocated buffer to the next filter. > > The gain would be: > - avoiding allocating a buffer during the HS when unwrap does not > produce anything > - creating smaller objects in the standard processing (ie data processing) > > Emmanuel > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
