-
Bug
-
Resolution: Done
-
Critical
-
None
-
None
-
False
-
None
-
False
-
-
Intermittent issue causes some consumers to linger on the server, even though the underlying connection is apparently destroyed. netstat output confirms the TCP connection is no longer in existence. The following OQL demonstrates the issue:
SELECT toString(consumer.messageQueue.name.str) AS queue_name, consumer.session.remotingConnection.transportConnection.channel.remote.toString() AS remote_address, consumer.session.closed AS session_closed, consumer.isClosed AS consumer_closed, consumer.session.remotingConnection.destroyed AS connection_destroyed, consumer.session.remotingConnection.transportConnection.channel.id.shortValue.toString() AS connection_id, deliveringRefs.tail AS delivering_tail, deliveringRefs.head AS delivering_head, deliveringRefs.elements.@length AS delivering_deque_length FROM org.apache.activemq.artemis.core.server.impl.ServerConsumerImpl consumer WHERE ((toString(consumer.binding.queue.name.str) = "<REDACTED>") AND (consumer.session.remotingConnection.transportConnection.channel.remote.toString() = "<REDACTED>"))
The above output shows shows messages in delivery, consumer open, session open, but connection destroyed. The delivery count (deque_length - head + tail) aligns with the delivering count in the image provided by the customer.
The practical implication here is that the client no longer exists, messages are in delivery and not eligible to be redelivered to another consumer, and the consumer will never be cleaned up until broker restart.