Major Description
JournalStorageManager::addBytesToLargeMessage and LargeServerMessageImpl::DecodingContext::encode are relying on the pooling of direct ByteBuffers performed internally by NIO.
Those buffers are pooled until certain size limit (ie jdk.nio.maxCachedBufferSize, as shown on https://bugs.openjdk.java.net/browse/JDK-8147468) otherwise are freed right after the write succeed.
If the property jdk.nio.maxCachedBufferSize isn't set, the direct buffers are always pooled regardless of the size, leading to OOM issues on high load of variable sized writes due to the amount of direct memory allocated and not released/late released.
This should be an alternative fix for https://issues.apache.org/jira/browse/ARTEMIS-1811 and it check if such pooling is happening, making large messages to be read/written in chunks by using the Netty ByteBuf pool to handle any intermediate buffer.
Attachments
Issue Links
- links to
