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
_AMQ_NotifType=BINDING_ADDED, _AMQ_FilterString=bridgeId = '10025',
_AMQ_Binding_ID=44, _AMQ_Distance=0, _AMQ_Binding_Type=0}
CONSUMER_CREATED: Received ActiveMQ notification for
_AMQ_User=guest, _AMQ_ConsumerCount=1, _AMQ_RemoteAddress=/127.0.0.1:64817,
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
CONSUMER_CLOSED: Received ActiveMQ notification for
_AMQ_User=guest, _AMQ_ConsumerCount=0, _AMQ_RemoteAddress=/127.0.0.1:64817,
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
Please let me know if you would like any further information.
View this message in context:
Sent from the ActiveMQ - User mailing list archive at Nabble.com.