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. On Fri, Jan 14, 2022 at 7:38 AM Jonathan Valliere <[email protected]> wrote: > Please point to the line of code in GitHub. GitHub has a great tool for > linking directly to lines. > > On Fri, Jan 14, 2022 at 3:49 AM Emmanuel Lécharny <[email protected]> > wrote: > >> Hi, >> >> I'm reviewing some parts of MINA (more specifically the SSL part), and I >> found that we default the read buffer to 2048 bytes, which seems a bit >> too small to me. >> >> Typically, when handling TLS messages, we may have up to 16384 PDUs >> (max). If the buffer is too small, we havve to do some extra read up to >> the point we have received all the needed data. >> >> At this point, I wonder if it wouldn't be a better idea to size the >> buffer to at least the max PDU size of a TLS message (ie 16384 bytes). >> >> The drawback is that it may be more demanding on the GC, as we will >> allocate bigger buffers for each incoming message. >> >> >> Incenditally I wonder if it wouldn't be a good idea to use a Thread >> Local Storage to keep the allocated buffer, and avoiding the allocation >> of such a buffer for every call (assuming we copy it if there is an >> executor in the chain). >> >> >> Thoughts ? >> >> -- >> Emmanuel Lécharny >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >>
