Mailing-List: contact users-help@activemq.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@activemq.apache.org
Received-SPF: pass (nike.apache.org: domain of lists@nabble.com designates
 216.139.236.158 as permitted sender)
Message-ID: <28771545.post@talk.nabble.com>
Date: Thu, 3 Jun 2010 11:53:41 -0700 (PDT)
From: Thomas Lockney <tlockney@gmail.com>
To: users@activemq.apache.org
Subject: Problems with lingering ActiveMQTempQueue objects
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


I'm seeing a problem in a production application where it appears that
instances of ActiveMQTempQueue are not going away. What's happening is that
our apps send messages intended for remote agents. The agents speak to our
servers through a servlet frontend, so essentially we're proxying ActiveMQ
(it's a bit more complicated than that, but hopefully that gives the
essential picture).

I'm using temporary response queues as per the JMS spec and attaching these
to the message using setJMSReplyTo(responseQueue). The calling code then
sits and waits for the response or times out and then closes the connection.
On servlet side, these messages come in from ActiveMQ and when the
appropriate agent connects, get sent down. The servlet-side code has a local
map of the messages so that when the response comes back from the agent, it
can reference the response queue and send back the data. At this point, the
object which holds the reference to the response queue is removed from the
map.

Over the course of a few days, we end up seeing all the heap space on the
servlet-side JVMs disappearing. I've started taking hourly heap dumps and
I'm seeing the number of ActiveMQTempQueue objects quickly increasing. In
one case right now, I'm seeing one of our JVMs has nearly 2 million of these
objects! My initial thought on seeing this was that the objects which
referenced them were not getting removed correctly from the map and
therefore were not getting GCed. But there are only about 3000 of those in
the heap right now -- that's about a typical number we'd expect to see given
the usage of our system.

I've been reading through old threads on this list for possible answers, but
it looks like most of the solutions to past problems have already been
rolled into the source. We're using ActiveMQ 5.2.0 for what it's worth. I've
tried manually deleting the temp queues after sending back the response, but
that doesn't appear to effect anything. I've also tried modifying the
ActiveMQ source so that setAutoCreateDestinations(false) is called in the
constructor of TempQueueRegion, based on info from this thread:
http://old.nabble.com/Problems-with-prefetch-and-TemporaryQueues-tt27130529.html#a27130529

I'm trying to figure out if there's anything else I might be missing. I'm
tempted to rework all this to use a single response topic with message
selectors using a unique response ID, but I've had performance problems in
the past with selectors, so I'm hesitant to go that route if there might be
an obvious solution here that I'm missing. 

Any ideas?

~thomas
-- 
View this message in context: http://old.nabble.com/Problems-with-lingering-ActiveMQTempQueue-objects-tp28771545p28771545.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.