Isn't ServiceInvoker.deliverSync flawed?

[ewrdk]

Looking at the underlying code (Community Edition 4.4.GA) of the ServiceInvoker I can see the following (JMS epr case):

The ingoing message is delivered using TwoWayCourierImpl which in turn uses JMSCourier. The JMSCourier sets the correlationId of the message. So far so good.

But when retrieving the outgoing message this correlationId is never used: The pickup method of JMSCourier does not use a message-selector based on the correlationId (it can only use a generic message-selector attached to the jms-filter definition).

This in turn means that there is no guarantee that the response message is related to the request message. For a single user scenario this may work, except that previous timed-out messages may be returned instead. In a multi-threaded scenario it will never work. This is f.ex. the case with the RequestResponseBaseWebService class in the Enterprise 4.3 edition.

So, have I missed something here?

[kconner]

"ewrdk" wrote:
So, have I missed something here?

You missed the fact that it is driven through the EPR and message selector.

My suspicion, given your description so far, is that you may be suffering from a bug that has been fixed in the CP branches and will shortly be fixed in trunk (for ESB 4.5).

If you can provide a better description of your real issue then we may be able to confirm this.

[ewrdk]

From your feedback I've discovered that DefaultJmsReplyToEpr class indeed sets a message selector.

But this class is only used when you are using the default reply queue (_reply). But if you use a non-default reply queue then the message selector will not be set.

So as far as I can tell there is a subtle contract saying that you must use the default replyTo queue when using ServiceInvoker.

[kconner]

You can use other EPRs or queues if you wish but you are then responsible for handling the request/response correlation. We handle the common case, that of request/response using an associated queue, but you are not confined to this.

As an example, there is no reason why any response EPR must match the transport used for a request and, as such, the jms correlation id is not necessarily the identifier which should be used.

What is it that you are trying to achieve?