Re: potential memory leak when using STOMP protocol

[mcacker]

I have opened https://issues.apache.org/jira/browse/ARTEMIS-741.

I tried modifying the StompTest, but have had too many issues getting
Artemis building fully in Eclipse (JDK8?).



--
View this message in context: 
http://activemq.2283324.n4.nabble.com/potential-memory-leak-when-using-STOMP-protocol-tp4716643p4716674.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.

Re: potential memory leak when using STOMP protocol

[Justin Bertram]

This is likely a bug.  Can you open a JIRA at 
https://issues.apache.org/jira/browse/ARTEMIS and describe how to reproduce?  
Even better would be a test-case (e.g. added to 
org.apache.activemq.artemis.tests.integration.stomp.StompTest).

Thanks!


Justin

- Original Message -
From: "mcacker" 
To: users@activemq.apache.org
Sent: Monday, September 19, 2016 7:08:41 PM
Subject: potential memory leak when using STOMP protocol

Hi,

I have a scenario which looks very much like a server memory leak when using
STOMP protocol.  I've upgraded (from HornetQ) to the latest ArtemisMQ 1.4.0,
and the same behaviour is exhibited in both products.

I have a server with a topic:

  

  

to which I create a STOMP connection, followed by a STOMP subscription which
includes a selector:

BINDING_ADDED: Received ActiveMQ notification for
10.2.62.211{_AMQ_Address=jms.topic.asyncEvents,
_AMQ_NotifType=BINDING_ADDED, _AMQ_FilterString=bridgeId = '10025',
_AMQ_RoutingName=4d21b2db-7ec5-11e6-9772-0023243daaea,
_AMQ_NotifTimestamp=1474329654909,
foobar=4d21b2dc-7ec5-11e6-9772-0023243daaea, JMSXDeliveryCount=1,
_AMQ_ClusterName=4d21b2db-7ec5-11e6-9772-0023243daaea42503b61-7ec5-11e6-9772-0023243daaea,
_AMQ_Binding_ID=44, _AMQ_Distance=0, _AMQ_Binding_Type=0}
CONSUMER_CREATED: Received ActiveMQ notification for
10.2.62.211{_AMQ_Address=jms.topic.asyncEvents,
_AMQ_NotifType=CONSUMER_CREATED,
_AMQ_RoutingName=4d21b2db-7ec5-11e6-9772-0023243daaea,
_AMQ_NotifTimestamp=1474329654913, JMSXDeliveryCount=1,
_AMQ_SessionName=4d141e48-7ec5-11e6-9772-0023243daaea,
_AMQ_ClusterName=4d21b2db-7ec5-11e6-9772-0023243daaea42503b61-7ec5-11e6-9772-0023243daaea,
_AMQ_User=guest, _AMQ_ConsumerCount=1, _AMQ_RemoteAddress=/127.0.0.1:64817,
_AMQ_Distance=0}

A heap dump at this point shows that the server instantiates a QueueImpl for
the topic selector. The application then performs some processing resulting
in message publishing to the topic.  All the messages are deliverd, and all
is good at this point.

The client then unsubscribes from the topic selector, but does not close the
connection.

CONSUMER_CLOSED: Received ActiveMQ notification for
10.2.62.211{_AMQ_Address=jms.topic.asyncEvents,
_AMQ_NotifType=CONSUMER_CLOSED,
_AMQ_RoutingName=4d21b2db-7ec5-11e6-9772-0023243daaea,
_AMQ_NotifTimestamp=1474329846463, JMSXDeliveryCount=1,
_AMQ_SessionName=4d141e48-7ec5-11e6-9772-0023243daaea,
_AMQ_ClusterName=4d21b2db-7ec5-11e6-9772-0023243daaea42503b61-7ec5-11e6-9772-0023243daaea,
_AMQ_User=guest, _AMQ_ConsumerCount=0, _AMQ_RemoteAddress=/127.0.0.1:64817,
_AMQ_Distance=0}

A second heap dump shows that the server still has the QueueImpl object, but
with no consumer (the ConsumerList is empty), but which retains the selector
(filter).  Upon publishing further messages to the topic, the QueueImpl
queues these messages in its messageReferences queue, and never cleans them
up, which ultimately kills the server.

I have compared this scenario to a similar one using Netty, but in that
instance, the server behaves correctly, and removes the QueueImpl object for
the netty consumer, and no memory leak results.

Having looked at the STOMP protocol, it appear to be valid use of Connect,
Subscribe and Unsubscribe, but regardless, it shouldn't result in such a
significant memory leak.

Is something misconfigured in the application, or is this a genuine memory
leak?

Please let me know if you would like any further information. 

thanks, Mitchell




--
View this message in context: 
http://activemq.2283324.n4.nabble.com/potential-memory-leak-when-using-STOMP-protocol-tp4716643.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.