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