Continuing the thoughts from the previous post....

Adding two sets of source/destination is pretty trivial (Perhaps differentiate bridges by calling them OneWayBridge and TwoWayBridge?).

Without using temp destinations we could just keep track of original messageid's and original ReplyTo destinations from JBM and their corresponding remote messageid. Then, when the message is received from the remote provider (using JMSCorrelationId to link request/response), we could look up the correlationid on it and find the original data, replacing it before sending to a JBM destination.

A lookup table would need:

originalJBMJMSMessageId - originalJBMReplyTo - remoteJMSMessageId

With temp destinations it becomes even more powerful (but requires more support on the remote side, both client and server). In this case we don't need to keep track of the remote messageid, since we know that messages received on the temp destination are a reply to a specific JBM message. The downside is that the receiving part of the bridge would need to listen to a temp destination (or use unique selectors on a shared destination). Come to think of it, selectors would actually suffice and be cleaner, but maybe theres an anti-pattern there somewhere.

* JMS Message arrives at a JBM destination
* TwoWayBridge receives it, sees that it has a ReplyTo destination, keeps track of the original replyto destination and jmsmessageid
* TWB creates a remote temp destination
* TWB sends the message with the remote temp destination as the ReplyTo value, after send() it adds the remoteJMSMessageId to the same record
* TWB begins listening on the remote temp queue (it now knows which message it is waiting for a response to)
* TWB receives a response from the remote provider on the temp destination
* TWB replaces the correlationid and the replyto values with the original ones
* TWB sends to a JBM destination

"thomasra" wrote:

* JMS Message arrives at a JBM destination
* TwoWayBridge receives it, sees that it has a ReplyTo destination, keeps track of the original replyto destination and jmsmessageid
* TWB creates a remote temp destination
* TWB sends the message with the remote temp destination as the ReplyTo value, after send() it adds the remoteJMSMessageId to the same record
* TWB begins listening on the remote temp queue (it now knows which message it is waiting for a response to)
* TWB receives a response from the remote provider on the temp destination
* TWB replaces the correlationid and the replyto values with the original ones
* TWB sends to a JBM destination

Actually, JMS 1.1 section 5.10 QueueRequestor already does the temp stuff for us, so we could just thread out a QueueRequestor from the Bridge when sending to the remote provider, it will block until a response is received, and then we know what this is a response to.

It could be as simple as this perhaps (from inside the sendBatch method in Bridge):

 // Differentiate between messages that require a reply
 Destination originalDestination = msg.getJMSReplyTo();
 if(originalDestination == null) {
 producer.send(msg);
 } else {
 // This probably needs to be spawned in a separate thread so it doesn't block
 QueueRequestor q = new QueueRequestor((QueueSession) targetSession, (Queue) producer.getDestination());
 Message response = q.request(msg);
 producer.send(originalDestination, response); // This isn't the correct producer, though
 }

I agree the correlation bit isn't necessary if we use temp queues, however, the JMS spec intent on using those fields (albeit on a single provider) is something that would be very nice to have.

I went along and changed Bridge.java to test this using temp queues, by adding an inner class that is a Runnable, and then using QueueRequestor. Then the bridge would just spawn the inner class in a new thread, which blocks until a response arrives, and then it switches ReplyTo back again to the original values. I haven't thought about the overhead of creating/closing temp queues, so that is valuable input.

Atleast if things were implemented this way we wouldn't have to keep a mapping (the Runnable is given the necessary state through the constructor).

I see some problems with this, but they might be trivial to implement:

* Threading and replies that don't arrive (we would need to set a timeout and handle the situation)
* Pooling the threads so things don't get out of hand
* Reduce performance hit by reusing temp queues for a session

Oh, and I am testing the bridge using activemq as the remote provider, and will gather some experiences with this that I can give you.

Any more?

Oh, and I'm not a big fan of using properties on the message since that implicitly ties the client to using "our" semantics. I think it is better to keep things as transient to the remote client as possible.

BTW: In order to get Bridge to work with activemq (via a resource adapter) I had to update the sendBatch method and create a new javax.jms.Message, copying properties since the current implementation is tied to JBossMessage and complains when using a foreign destination.

Well, after deploying the activemq rar according to online docs, when I configured Bridge to use an activemq queue as the target (and a local queue as the source) it began complaining about not supporting "foreign" destinations, since it was attempting to set a destination from one implementation on a message from another.

To elaborate further:

The code in question does this:

producer.send(msg);