activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jörg Henne (JIRA) <j...@apache.org>
Subject [jira] Updated: (AMQ-2214) Announcement of new temporary queue may lose race with message pointing to it in network of brokers.
Date Tue, 21 Apr 2009 10:43:32 GMT

     [ https://issues.apache.org/activemq/browse/AMQ-2214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Jörg Henne updated AMQ-2214:
----------------------------

    Summary: Announcement of new temporary queue may lose race with message pointing to it
in network of brokers.  (was: Announcement of new temporary queue may lose race with message
pointing to it in metwork of brokers.)

> 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
>
> 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.


Mime
View raw message