Hello Team,

a java client using the Artemis 2.30. CORE libs called echosender is 
receiving rather big (10MB) messages and simply echoing the body back 
to the jmsReplyTo destination. It is otherwise completely stateless and 
handles only one message at a time.

A requester sends serialized requests: Another requests is not created or 
sent, before the previous reply was received.
The echosender grows in memory. Starting with 16 M used memory before 
requests start,
The request series blows the heap up to over 250M. 
The memory goes back when the requests are stopped. (even forcing gc it 
never goes down to the initial value again)
The client OS is Win2019 server, Brokers are on RHEL 8. 

To make the Test pass I had to raise JVM Memory from -Xms32m -Xmx64m to 
-Xms32m -Xmx516m
otherwise:

java.lang.OutOfMemoryError: Java heap space
at 
io.netty.util.internal.PlatformDependent.allocateUninitializedArray(PlatformDependent.java:325)
at 
io.netty.buffer.UnpooledUnsafeHeapByteBuf.allocateArray(UnpooledUnsafeHeapByteBuf.java:39)
at 
io.netty.buffer.UnpooledByteBufAllocator$InstrumentedUnpooledUnsafeHeapByteBuf.allocateArray(UnpooledByteBufAllocator.java:144)
at 
io.netty.buffer.UnpooledHeapByteBuf.capacity(UnpooledHeapByteBuf.java:133)
at io.netty.buffer.DuplicatedByteBuf.capacity(DuplicatedByteBuf.java:89)
at 
io.netty.buffer.AbstractByteBuf.ensureWritable0(AbstractByteBuf.java:305)
at 
io.netty.buffer.AbstractByteBuf.ensureWritable(AbstractByteBuf.java:280)
at io.netty.buffer.AbstractByteBuf.writeBytes(AbstractByteBuf.java:1073)
at io.netty.buffer.AbstractByteBuf.writeBytes(AbstractByteBuf.java:1081)
at io.netty.buffer.WrappedByteBuf.writeBytes(WrappedByteBuf.java:798)
at 
org.apache.activemq.artemis.api.core.SimpleString.writeSimpleString(SimpleString.java:198)
at 
org.apache.activemq.artemis.api.core.SimpleString.writeNullableSimpleString(SimpleString.java:191)
at 
org.apache.activemq.artemis.core.buffers.impl.ChannelBufferWrapper.writeNullableSimpleString(ChannelBufferWrapper.java:150)
at 
org.apache.activemq.artemis.core.buffers.impl.ResetLimitWrappedActiveMQBuffer.writeNullableSimpleString(ResetLimitWrappedActiveMQBuffer.java:339)
at 
org.apache.activemq.artemis.reader.TextMessageUtil.writeBodyText(TextMessageUtil.java:29)

Can somebody confirm my observation?
Why is the client keeping memory for data that is already sent?
Can I limit the observed buffer somehow?
Is the effect related to the entries I found in the broker log at the time 
of the tests?
On broker a large sequence of messages like this is written (please note 
there are hundreds
of identicall in some millisecond.

2023-12-12 14:33:37,830 WARN  [org.apache.activemq.artemis.core.server] 
AMQ222107: Cleared up resources for session 
0aefd156-98e7-11ee-9809-0050568d757e
2023-12-12 14:33:37,830 WARN  [org.apache.activemq.artemis.core.server] 
AMQ222061: Client connection failed, clearing up resources for session 
0aefd157-98e7-11ee-9809-0050568d757e
2023-12-12 14:33:37,830 WARN  [org.apache.activemq.artemis.core.server] 
AMQ222107: Cleared up resources for session 
0aefd157-98e7-11ee-9809-0050568d757e
2023-12-12 14:33:37,830 WARN  [org.apache.activemq.artemis.core.server] 
AMQ222061: Client connection failed, clearing up resources for session 
0aefd158-98e7-11ee-9809-0050568d757e
2023-12-12 14:33:37,830 WARN  [org.apache.activemq.artemis.core.server] 
AMQ222107: Cleared up resources for session 
0aefd158-98e7-11ee-9809-0050568d757e
2023-12-12 14:33:37,830 WARN  [org.apache.activemq.artemis.core.server] 
AMQ222061: Client connection failed, clearing up resources for session 
0aefd159-98e7-11ee-9809-0050568d757e
2023-12-12 14:33:37,830 WARN  [org.apache.activemq.artemis.core.server] 
AMQ222107: Cleared up resources for session 
0aefd159-98e7-11ee-9809-0050568d757e
2023-12-12 14:33:37,830 WARN  [org.apache.activemq.artemis.core.server] 
AMQ222061: Client connection failed, clearing up resources for session 
0af094aa-98e7-11ee-9809-0050568d757e

Regards

Herbert



Reply via email to