[
https://issues.apache.org/activemq/browse/AMQ-2214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=51322#action_51322
]
Jörg Henne commented on AMQ-2214:
---------------------------------
No, I didn't. My bad. My excuse for this is that the way I read [the comment
about
watchTopicAdvisories|https://issues.apache.org/activemq/browse/AMQ-1176?focusedCommentId=38589&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_38589]
I gathered that this was a work-around which was no longer needed due to the
code change and this only applied to topics.
There is no Javadoc for ActiveMQConnectionFactory.watchTopicAdvisories - is
there any description of the implications of setting this to false?
Thanks!
> Announcement of new temporary queue may lose race with message pointing to it
> in network of brokers.
> ----------------------------------------------------------------------------------------------------
>
> Key: AMQ-2214
> URL: https://issues.apache.org/activemq/browse/AMQ-2214
> Project: ActiveMQ
> Issue Type: Bug
> Components: Broker
> Affects Versions: 5.2.0
> Reporter: Jörg Henne
> Attachments: broker.xml, Client.java, Server.java
>
>
> h4. Scenario:
> * one well-known initiation queue is used by
> * clients and servers to
> * establish a private session using a pair of temporary queues:
> ## client creates temporary queue
> ## creates message with reply-to pointing to temporary queue
> ## sends message to initiation queue
> ## server receives initiation message
> ## creates temporary queue
> ## replys with handshake reply with reply-to pointing to second temporary
> queue
> * clients repeatedly exercise this chat scenario
> * communication is provided over a network of brokers which is established
> using auto discovery.
> h4. Problem:
> When this scenario is executed over a network of brokers, sometimes the
> temporary queue has not yet been established thoughout the network of brokers
> when one of the partners already received a message with reply-to set to the
> temporary queue. This leads to exceptions like this:
> {noformat}
> javax.jms.InvalidDestinationException: Cannot publish to a deleted
> Destination: temp-queue://ID:jh-xp-2-1250-1240304283337-2:0:378
> at org.apache.activemq.ActiveMQSession.send(ActiveMQSession.java:1597)
> at
> org.apache.activemq.ActiveMQMessageProducer.send(ActiveMQMessageProducer.java:227)
> at
> org.apache.activemq.ActiveMQMessageProducerSupport.send(ActiveMQMessageProducerSupport.java:241)
> at Client.chat(Client.java:46)
> at Client.main(Client.java:78)
> {noformat}
> The problem seems to be heavily timing-dependant as it is very hard to
> reproduce with several brokers running on the same machine. However, it is
> more easily reproduced with brokers running in separate virtual machines (VM
> as in VMWare) or even distributed across real hardware.
> h4. Work-around
> A work-around for this problem (and the proof that the temporary queue
> "springs into existence" shortly after the exception is thrown) is depicted
> in the following retry code:
> {code}
> int trys = 5;
> while (true)
> try {
> MessageProducer cp = s.createProducer(rq);
> cp.send(s.createTextMessage(rr));
> break;
> } catch (InvalidDestinationException e) {
> if (--trys > 0) {
> logger.error("Got InvalidDestinationException -
> retrying " + trys, e);
> Thread.sleep(100);
> continue;
> } else
> throw e;
> }
> {code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
