activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Lockney <>
Subject Re: Problems with lingering ActiveMQTempQueue objects
Date Thu, 03 Jun 2010 19:36:13 GMT

> > I'm using temporary response queues as per the JMS spec and attaching
> > to the message using setJMSReplyTo(responseQueue). The calling code then
> > sits and waits for the response or times out and then closes the
> connection.
> Sorry, did I understand correctly and you create a new temporary queue
> per every request?

Not exactly. For any messages sent by the backend service that expect a
reply, we create a new temp queue and attach it to the source message. Since
the temporary queue objects are supposed to be closed, as defined by the JMS
API, when the original connection is closed, creating a new temp queue per
source message seemed the right way to do it. In fact, all of the docs and
discussions I read implied that was the way you *must* do it for reliable

> We use one or few temporary (or even normal) queues, attach them to
> requests using setJMSReplyTo(responseQueue) and match replies by
> correlation Id. Therefore, a response queue is (re-)used for multiple
> requests, normally until connection to ActiveMQ broker is broken for
> some reason.

Right, that's the approach I'm considering if I can't figure out why these
objects are hanging around. I might give it a go anyway, since we're in
desperate need of a fix here. Of course, it's a balancing act -- this code
is already in production and was working fine until we started getting heavy
usage on this new system. So the ideal fix is one that changes the least
amount of code, but perhaps it will require a more invasive fix to truly
address the underlying issue.

> Creation of any queue or topic is a sync request to broker. Creation
> of consumer is another sync request to broker. Same for producers and
> sessions. So, for optimal performance you should cache all these
> objects and reuse them for as many requests as possible.

Actually, that touches on the other issues (which actually clued us into the
source of the problem in the first place) -- since all these
ActiveMQTempQueue objects are hanging around and not getting cleaned up,
they are eating up network bandwidth as they communicate with the ActiveMQ
brokers. It isn't high enough to cause us any heartache, yet, but it made
the problem obvious.
View this message in context:
Sent from the ActiveMQ - User mailing list archive at

View raw message