activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Zemus <>
Subject Re: Problems with prefetch and TemporaryQueues
Date Wed, 13 Jan 2010 15:41:03 GMT

Zemus wrote:
> Hi,
> I have a problem where TemporaryQueues are left (with 0 consumers) after
> the applications creating them have finished.
> This scenario occurs for both ActiveMQ 4.1.1 and 5.3.0 on my P4 2.6 GHz, 3
> GB RAM, Ubuntu 9.10, Sun JDK, default settings for ActiveMQ.
> I've tried to recreate a simpler version of the scenario. Basically I have
> a server that creates a Topic where clients that wants to subscribe may
> post a message (with a TemporaryQueue as the JMS reply) in order to be
> added. The server then has a thread that sends messages to all the
> TemporaryQueues. (I know a simple Topic could push the updates here, but
> in the real system the clients can receive information only intended for
> one single client.)
> In my scenario the server is faster at generating messages than the
> clients are in processing them so the queues start to build up. Pretty
> soon (if clients are added and removed once a minute or so) it will hit a
> limit and the processing of messages in the broker seems to come to a
> halt. I think it is when the prefetch limit is reached.
> The real problem here is that if a client disconnects successfully (might
> hang in the broker communication) it is possible for the server to
> "resurrect" its TemporaryQueue, probably by sending prefetchbuffered
> messages to it. This way the TemporaryQueue is left on the broker with no
> consumer (the client disconnected) with its queued up messages counting
> towards the prefetch limit.
> By running JConsole and purging the queue I can get the broker to wake up,
> but if many messages are queued up the consumerless TempQueue will queue
> those messages which might again cause the prefetch limit to be reached
> and halt the broker.
> Also, I've seen old TemporaryQueues that were removed minutes ago come
> back and start queueing buffered messages when I start purging other
> consumerless TempQueues.
> In short I think there are two problems here.
> First, the detection of the client disconnection is not instant on the
> server. This makes it possible to send messages to the TemporaryQueue
> without getting an exception after it should have been removed.
> The second is that the TemporaryQueue is able to resurrect after its
> creator/consumer has left. In other words it has outlived its connection.
> I attach a simple client and server that are able to reproduce this
> reliably (at least on my computer).
> Just run the server and maybe two clients. Restart the clients perhaps 1-2
> times per minute and the issue will show pretty quickly. At least on my
> P4, maybe a computer with multiple cores will behave different.
> Regards
> Zemus

After more investigation I've changed my mind about the nature of the
problem. The prefetch limit is not involved.

My new theory goes like this:

1. The temporary queue is removed correctly when the client exists and
closes its connection.

2. The server might receive an exception when it tries to send to the
removed temporary queue. BUT sometimes it doesn't get that exception
(perhaps because the broker was soo busy that it didn't have time to notify
the activemq part of the server in time) and instead the broker creates a
new queue with the same name, although without any consumer, when the server
sends the next message to the stored destination.

3. The server knows nothing about this and keeps sending messages that pile
up in the broker, which in turn, eventually runs out of memory (at least
jconsole reports MemoryPercentageUsed 100 for the broker object).

If this sounds reasonable, my questions are instead:

* How can I prevent the broker from creating a new temporary queue because
of the server's late message?

* Would listening to advisory support for the temp queue at the server side
notify me in time to stop the sending of any more messages when the temp
queue is removed?

* Or is there a better way that would stop the server from sending a message
to a removed temp queue?


View this message in context:
Sent from the ActiveMQ - User mailing list archive at

View raw message