[prev in list] [next in list] [prev in thread] [next in thread] 

List:       activemq-users
Subject:    Re: Controlling the Netty messagebuffer
From:       Justin Bertram <jbertram () apache ! org>
Date:       2023-12-13 15:33:45
Message-ID: CAF+kE=RH7iKDuMM-U6xZ5o7vFbjit8ZPrwXHdR+OXfp4FcZ_WQ () mail ! gmail ! com
[Download RAW message or body]


> Can somebody confirm my observation?

You'd need to share your application code in order to confirm. Feel free to
create a GitHub repo or something including the requester and responder.

> Why is the client keeping memory for data that is already sent?

Unknown at this point.

> Can I limit the observed buffer somehow?

Unknown at this point.

> Is the effect related to the entries I found in the broker log at the
time of the tests?

Unknown at this point. Those messages might be the result of the OOME on
the client which almost certainly would have caused the connection to fail
without being closed properly.


Justin

On Tue, Dec 12, 2023 at 10:03 AM <Herbert.Helmstreit@systema.com> wrote:

> 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
> 
> ------------------------------
> 
> *Herbert Helmstreit*
> Senior Software Engineer
> 
> Phone: +49 941 / 7 83 92 36
> Herbert.Helmstreit@systema.com
> 
> www.systema.com
> 
> [image: LinkedIn] <https://www.linkedin.com/company/systema-gmbh/>[image:
> Facebook] <https://de-de.facebook.com/SYSTEMA.automation/>[image: XING]
> <https://www.xing.com/pages/systemagmbh>
> 
> SYSTEMA
> Systementwicklung Dipl.-Inf. Manfred Austen GmbH
> 
> Manfred-von-Ardenne-Ring 6 | 01099 Dresden
> HRB 11256 Amtsgericht Dresden | USt.-ID DE 159 607 786
> Geschäftsführer: Manfred Austen, CEO und Dr. Ulf Martin, COO
> 
> P Please check whether a printout of this e-mail is really necessary.
> 
> 



[prev in list] [next in list] [prev in thread] [next in thread]