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.
Same thing in 2.1.X:
https://github.com/apache/mina/blob/e49579069e49d733d8f75bc67b2e16311b619ffe/mina-core/src/main/java/org/apache/mina/filter/ssl/SslHandler.java#L762
private SSLEngineResult unwrap() throws SSLException {
// We first have to create the application buffer if it does
not exist
if (appBuffer == null) {
appBuffer = IoBuffer.allocate(inNetBuffer.remaining());
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.
Yep, but I think it should be the responsability of the executor to deal
with a buffer copy, otherwise we should pass the buffer up the stream
without any copy. Thus a TLS buffer could be safely used.
Btw, we also copy the incoming buffer *before* passing it to the SslEngine:
https://github.com/apache/mina/blob/e49579069e49d733d8f75bc67b2e16311b619ffe/mina-core/src/main/java/org/apache/mina/filter/ssl/SslHandler.java#L348
SslHandler.messageReceived(NextFilter nextFilter, ByteBuffer buf)
throws SSLException {
...
// append buf to inNetBuffer
if (inNetBuffer == null) {
inNetBuffer =
IoBuffer.allocate(buf.remaining()).setAutoExpand(true);
}
inNetBuffer.put(buf);
...
unless we have more data in the buffer to process:
https://github.com/apache/mina/blob/e49579069e49d733d8f75bc67b2e16311b619ffe/mina-core/src/main/java/org/apache/mina/filter/ssl/SslHandler.java#L365
// prepare to be written again
if (inNetBuffer.hasRemaining()) {
inNetBuffer.compact();
} else {
inNetBuffer.free();
inNetBuffer = null;
}
That is a waste, IMO
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]
--
*Emmanuel Lécharny - CTO* 205 Promenade des Anglais – 06200 NICE
T. +33 (0)4 89 97 36 50
P. +33 (0)6 08 33 32 61
[email protected] https://www.busit.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
