[
https://issues.apache.org/jira/browse/ARTEMIS-2482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Bertram resolved ARTEMIS-2482.
-------------------------------------
Resolution: Abandoned
> Large messages could leak native ByteBuffers
> --------------------------------------------
>
> Key: ARTEMIS-2482
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2482
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: AMQP, Broker, OpenWire
> Affects Versions: 2.10.0
> Reporter: Francesco Nigro
> Priority: Major
> Time Spent: 8h
> Remaining Estimate: 0h
>
> 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.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
For further information, visit: https://activemq.apache.org/contact
