[ https://issues.apache.org/jira/browse/ARTEMIS-2482?focusedWorklogId=310442&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-310442 ]
ASF GitHub Bot logged work on ARTEMIS-2482: ------------------------------------------- Author: ASF GitHub Bot Created on: 11/Sep/19 09:43 Start Date: 11/Sep/19 09:43 Worklog Time Spent: 10m Work Description: franz1981 commented on issue #2832: ARTEMIS-2482 Large messages could leak native ByteBuffers URL: https://github.com/apache/activemq-artemis/pull/2832#issuecomment-530284944 @wy96f Yes and no :) They would leak (at first look, but let me take a better look), but they just contain wrappers to direct memory that cannot be released (is part of the pool and they have no cleaner). The impact should be way less then `IOUtil` that pool native `ByteBuffer`s holding exclusively native memory that won't be reused anymore... Ideally we shouldn't have *any* thread locals, but we use them for several stuff (including the NIO factories and page read/write): I'm planning to replaced them by using the Netty pool, because of the difference on how thread locals are used. Our thread locals in Artemis just hold memory that cannot be reused if not by the same thread, while for Netty, thread locals are just a way to cache wrappers that has a very limited impact on GC, while the pool really allows to reuse memory where is most needed... Just to add more detail: consider that `PooledBytebufAllocator.PoolThreadLocalCache::initialValue` contains this comment, while creating a thread-local `PoolThreadCache`: ``` @Override protected synchronized PoolThreadCache initialValue() { final PoolArena<byte[]> heapArena = leastUsedArena(heapArenas); final PoolArena<ByteBuffer> directArena = leastUsedArena(directArenas); Thread current = Thread.currentThread(); if (useCacheForAllThreads || current instanceof FastThreadLocalThread) { return new PoolThreadCache( heapArena, directArena, tinyCacheSize, smallCacheSize, normalCacheSize, DEFAULT_MAX_CACHED_BUFFER_CAPACITY, DEFAULT_CACHE_TRIM_INTERVAL); } // No caching so just use 0 as sizes. return new PoolThreadCache(heapArena, directArena, 0, 0, 0, 0, 0); } ``` So, if we are not very happy about the Netty caching on non-Netty threads, we can disable those caches on by setting `-Dio.netty.allocator.useCacheForAllThreads=false` ---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org Issue Time Tracking ------------------- Worklog Id: (was: 310442) Time Spent: 4h 10m (was: 4h) > 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: 4h 10m > 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.3.2#803003)