Bug 444742

Summary:	Using federation with temporary reply-to queues.
Product:	Red Hat Enterprise MRG	Reporter:	Alan Conway <aconway>
Component:	Release_Notes	Assignee:	Lana Brindley <lbrindle>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Kim van der Riet <kim.vdriet>
Severity:	urgent	Docs Contact:
Priority:	high
Version:	beta	CC:	mhideo, rattapat+nobody
Target Milestone:	Next Version	Keywords:	Documentation
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:	1.0	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2008-06-06 01:49:39 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Alan Conway 2008-04-30 13:34:03 UTC

Description of problem:

Want a JMS client to send sends messages via a federation link to a queue on a
remote broker with reply-to set to a temporary queue on the local broker. A
client of the remote broker should be able to send a reply back via a federation
link.

Currently this is not possible. There is no way to have the necessary return
link created automatically, and it cannot be created manually because the JMS
API does not reveal the name of the temporary queue.
 



Additional info:

Comment 1 Lana Brindley 2008-06-06 01:49:08 UTC

<row>
        <entry>
	        444742
        </entry>
	<entry>
		When a Java Messaging Service client attempts to send messages via a
federation link to a queue on a remote broker with reply-to set to a temporary
queue on the local broker. A client of the remote broker should be able to send
a reply back via a federation link.
	</entry>
	<entry>
		Currently this is not possible. There is no way to have the necessary return
link created automatically, and it cannot be created manually because the JMS
API does not reveal the name of the temporary queue.
	</entry>
</row>

Comment 2 Rajith Attapattu 2008-10-01 19:02:22 UTC

I have proposed a solution on the Qpid list which didn't get consensus.
Currently the JMS client allows to set the exchange to which the temp queues are bound. So we could try to stich a solution use this.
It would have been better if we agreed to configure the binding key as well bcos that would give us more flexibility.

I will play around with the temp queue exchange and see if we can get something going.