activemq-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kevin Bowman (JIRA)" <>
Subject [jira] [Commented] (AMQ-6155) Spurious InvalidDestinationException publishing to a temp queue from a new connection
Date Wed, 03 Feb 2016 19:19:39 GMT


Kevin Bowman commented on AMQ-6155:

Unfortunately, calling setWatchTopicAdvisories() is not an option as the original environment
was using JNDI to connect to ActiveMQ.  I couldn't find any way to set that parameter through
JNDI.  Our only workaround was to restructure how the application worked, which is not always
an option for us.

It also seems like if I had any kind of appreciable churn on temp queues and more than handful
of open connections then I would want this feature turned off purely for performance reasons.
 In normal usage, only one connection is ever going to care about any given temp queue.

> Spurious InvalidDestinationException publishing to a temp queue from a new connection
> -------------------------------------------------------------------------------------
>                 Key: AMQ-6155
>                 URL:
>             Project: ActiveMQ
>          Issue Type: Bug
>          Components: JMS client
>    Affects Versions: 5.10.2, 5.13.0
>         Environment: Windows, OS X
>            Reporter: Kevin Bowman
>         Attachments:
> When a new connection is opened for the purpose of sending a message to a temporary queue
it sometimes fails with the following exception (stack trace is from v5.13.0):
>  javax.jms.InvalidDestinationException: Cannot publish to a deleted Destination: temp-queue://ID:Potomac.local-59943-1454448412194-1:1:96
>  	at org.apache.activemq.ActiveMQSession.send(
>  	at org.apache.activemq.ActiveMQMessageProducer.send(
>  	at org.apache.activemq.ActiveMQMessageProducer.send(
>  	at org.apache.activemq.ActiveMQMessageProducerSupport.send(
> The actual problem appears to be in ActiveMQConnection.isDeleted().  Because the connection
being used to send to the temp queue is not the connection under which the temp queue was
created, it's dependent on AdvisoryConsumer to populate the activeTempDestinations map before
the send() call is made.  The AdvisoryConsumer gets called in a separate thread, asynchronous
with the main thread, so this constitutes a race condition.  If the send() call is made before
AdvisoryConsumer can notify the new connection of all existing temp queues then it will throw
an InvalidDestinationException even though the temp queue does actually exist.
> Calling setWatchTopicAdvisories(false) on the sending connection's factory alleviates
the problem and the program can run indefinitely with no errors.  Also, adding a delay before
the MessageProducer.send() call can alleviate the error somewhat, but with a small enough
delay it will still happen eventually.
> I noticed this first in an environment I don't have full control over.  It happened the
first time, every time, for reasons I still don't quite understand.  I have written a small
test program that reproduces the error outside of the original environment, but it runs in
a loop and it takes a few hundred iterations for it to occur.

This message was sent by Atlassian JIRA

View raw message