Minor Description
Because of some customization requirements, the readJournalFile method of JournalImpl needs to be calledmultiple times.
During the stress test, it was found that almost every 5 hours, the Broker appeared a Full GC.
This is the information about the Full GC in the GC log.
2018-07-25T12:14:07.323+0800: 10089.523: [Full GC (System.gc()) 6767M->253M(16G), 8.7138691 secs]
[Eden: 632.0M(712.0M)->0.0B(816.0M) Survivors: 104.0M->0.0B Heap: 6767.6M(16.0G)->253.9M(16.0G)], [Metaspace: 36323K->35961K(1083392K)]
[Times: user=2.56 sys=0.42, real=8.71 secs]
When the Full GC appears, the thread stack is as follows:
java.lang.System.gc(System.java:993)
java.nio.Bits.reserveMemory(Bits.java:666)
java.nio.DirectByteBuffer.<init>(DirectByteBuffer.java:123)
java.nio.ByteBuffer.allocateDirect(ByteBuffer.java:311)
org.apache.activemq.artemis.core.io.mapped.MappedSequentialFileFactory.newBuffer(MappedSequentialFileFactory.java:109)
org.apache.activemq.artemis.core.journal.impl.JournalImpl.readJournalFile(JournalImpl.java:463)
By analyzing the stack, it should be that the JVM's heap memory cannot be allocated, causing the JVM to call the System.gc() method.
In the Broker, MappedSequentialFileFactory caches off-heap memory through ThreadLocal. Once the thread is evicted by the CompactExecutor(keepalive is 60s) in the Journal, the heap memory is "leaked".
NIOSequentialFileFactory also has the same problem
