Request/Reply with JmsOutboundGateway and Reply-Topics

[nilsha]

Hi,

if I understand the sendAndReceive()-Method in the JmsOutboundGateway (Spring Integration 2.0) correctly, it first sends the message to its destination. Then it constructs a message consumer on the reply destination to wait for the answer.

I wonder if it would be possible to lost the reply message, in case (a) the reply-destination is a (non-temporarily) JMS Topic and (b) the reply comes (for whatever unlikely reason) so fast, that it arrives before the receive() on the message consumer is invoked.

Is it (theoretically) possible that this situation happens? Or do I miss something?

Thanks,
Nils

[Mark Fisher]

Is there a specific reason for using a "Topic" as a response Destination? It seems like a Queue would be a better choice.

[nilsha]

You're right, a Queue would be the better choice, but due to our Company's JMS policy we're forced to use Topics.

[Mark Fisher]

Okay. I just wanted to understand that first So, your question is valid. It seems that we would need to either create a durable subscriber or else have a separate thread for the consumer that starts prior to the producer sending the Message. Is that basically what you were suggesting?

[nilsha]

Yep, exactly :-)

For me a separate thread would be more comfortable than a Durable Subscriber: if the the server crashes before the reply is received, the reply would go into nirvana, which would be fine in that case IMHO. Having a Durable Subscriber (or a Queue), a Reply that will never be received (due to VM crash or similiar) would stay forever in the Queue/Durable Topic.

Disadvantages: more complex to implement(?) and you cannot use the JMS Message/Correlation-Id as selection criteria for the reply, as the Id is not known at the time you start to listening...

[Mark Fisher]

Yes, it's that correlationId part that's tricky...

[nilsha]

As always, I'm sure you find a solution :-)

Maybe it would be possible to use an extra JMS header with a self-generated id (UUID eg). Problem would be that the receiver is forced to include that header/the id in it's reply.

[Mark Fisher]

I did just want to mention that this should not be a problem at all when relying on temporary destinations. In fact, both QueueRequestor and TopicRequestor implementations (the vanilla JMS equivalent of our outbound gateway) do use TemporaryQueue and TemporaryTopic instances, respectively.

The only reason we do not simply rely upon those *Requestors is that we want to provide the *option* of using an explicit, potentially shared Destination along with the correlationID.

My next question, therefore, is if it would be sufficient to rely on a temporary Destination? If so, does even the creation of a temporary instance used only as a replyTo header need to conform to the Topic-only policy?

[nilsha]

I'm not sure, but I will check. Thank you very much so far.

BTW: maybe it would be helpful to add a hint in the documentation that messages can get lost when using Topics (as the API of JmsOutboundGateway supports that kind of destination)?

[Mark Fisher]

Out of curiosity, have you in fact witnessed lost Messages following that approach?