Clustering for temporary queues

[alexgvozdenovic]

Can someone please tell me if clustering should work for temporary queues.

Scenario is

Cluster of 2 nodes A, B.
Clustered queue Q1 is created.

A message consumer is bound to A and a message producer to B

Producer creates temp queue T and puts a message on Q1 with a 'replyTo' queue of T

Consumer receives message and sends a reply back on the specified queue.
The following error is then seen on A and on the consumer

2007-04-25 17:47:31,197 ERROR [org.jboss.jms.util.ExceptionUtil] SessionEndpoint[36] send [4sq2t1z-1t4cto-f0xx5dux-1-f0y0sprx-1s]
javax.jms.JMSException: Failed to route Reference[783872]:RELIABLE to 43363k4i-chuegy-f0y0t2g9-1-f0y0t3zt-b
at org.jboss.jms.server.endpoint.ServerConnectionEndpoint.sendMessage(ServerConnectionEndpoint.java:687)
at org.jboss.jms.server.endpoint.ServerSessionEndpoint.send(ServerSessionEndpoint.java:316)
at org.jboss.jms.server.endpoint.advised.SessionAdvised.org$jboss$jms$server$endpoint$advised$SessionAdvised$send$aop(SessionAdvised.java:80)
at org.jboss.jms.server.endpoint.advised.SessionAdvised$send_6145266547759487588.invokeNext(SessionAdvised$send_6145266547759487588.java)
at org.jboss.jms.server.container.SecurityAspect.handleSend
....etc etc

Could this be because the temporary queue info is not propagated fast enoug across the cluster?

[timfox]

We don't support clustering for temporary queues - when sending your reply you need to be on the same node for this to work.

I guess you have changed your message pull policy to be "DefaultMessagePullPolicy"?

Temporary queues are really designed to have a short life time (lifetime of the connection) therefore it doesn't make a lot of sense to have them living on other nodes. (Since who would consume from them on other nodes?)

Any reason why your queue has to be temporary?

[alexgvozdenovic]

Many thanks for the (very) prompt reply.

Yes, the pull policy is DefaultPullPolicy.

We are using temp queues to facilitate synchronous request/response semantics.

If this is not supported in a clustered setup, then I guess we can achieve the same using correlation ids and a shared reply queue.