activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Johle (JIRA)" <>
Subject [jira] [Commented] (AMQ-3488) Temporary destinations' DestinationInfo commands over VM transport prevent connection closure
Date Mon, 23 Apr 2012 17:48:38 GMT


David Johle commented on AMQ-3488:

I have some additional notes about some other side effects I've encountered that I can attribute
to this same bug.  Just posting them here in case anyone else not running 5.6.0 yet is running
into them and trying to figure out what is going on.

I noticed that, when using a temporary destination and then closing a connection and subsequently
receiving the "Consumer is consuming..." exception, the consumer for the queue I closed a
connection to was left dangling.

That is, I start up my application with X amount of consumers and look at the queue via JMX
under org.apache.activemq->myBrokerName->Queue->myQueuName->Attributes->Subscriptions
and see X amount subscriptions to that queue as expected.  I then instruct my application
to shut down Y amount of consumers, and the Subscriptions count remains at X instead of the
expected value of X - Y = Z.

If I disable the portion of my application that uses the temporary queue, then no exceptions
happen, and the above shutdown test does cause the Subscriptions count to drop to Z accordingly.

What's worse is that it's not just excess JMX ObjectNames left behind, but the actual consumer
subscriptions they relate to are also still there and registered with ActiveMQ / bound to
that queue as MessageListeners.  That can be verified via JMX as well, under org.apache.activemq->myBrokerName->Subscription->Non-Durable->Queue->myQueueName.

So what happens next is...

I then trigger my application to produce a bunch of messages into myQueueName.  Most of them
are consumed by the remaining Z consumers, but a certain number of them just get stuck in
the queue.  And not just any number, but precisely the number Y * prefetchSize.

If I restart my entire application the messages then get re-delivered to the fresh consumers
and flushed out of myQueueName.  That is, unless I don't get to it in time, at which point
they expire and end up in the DLQ instead.

Again, disabling the use of temporary qeueus avoids this issue.  The problem, of course, is
that I need the temps for proper app functionality!

I also tested this scenario with the current 5.6.0-SNAPSHOT and can confirm that it does indeed
resolve the issue.
> Temporary destinations' DestinationInfo commands over VM transport prevent connection
> ---------------------------------------------------------------------------------------------
>                 Key: AMQ-3488
>                 URL:
>             Project: ActiveMQ
>          Issue Type: Bug
>          Components: Transport
>    Affects Versions: 5.5.0
>            Reporter: Dan Retzlaff
>             Fix For: 5.6.0
>         Attachments:
> ActiveMQTempDestinations hold onto the source connection that created them. When the
source connection is closed, its temporary destinations are deleted. Unfortunately, DestinationInfo
commands convey the destination object with its source connection to all other connections
on the same VMTransportServer. Hence when these other connections are closed, they attempt
to delete the source connection's temporary destination.
> Note that enabling marshaling on the VM transport works around this bug because destination
serialization and deserialization does not maintain the source connection reference.
> This bug was not present in 5.4.2.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:!default.jspa
For more information on JIRA, see:


View raw message