Fwd: Camel jms - reply handling

[David Karlsen <da...@gmail.com>]

Crossposting dev as I got no attention on user@


---------- Forwarded message ----------
From: David Karlsen <da...@gmail.com>
Date: 2015-10-19 23:00 GMT+02:00
Subject: Camel jms - reply handling
To: users@camel.apache.org


Hi.

We're observing that camel-jms is slow when doing request/reply (from
the requesting side) using a shared replyQueue (setting correlationId
== receivedMessage id at the responding side) when queuedepth
increases. Underlying messaging middleware is IBM MQ. Looking at their
documentation it seems like requesting for a single correlationId (or
messageId) have certain optimizations we're missing when using a
shared replymanager ORing them toghether (however we need to dig
deeper into verifying that). [1] [2]

They're using camel 2.12.1 which is very old - so I've asked them to
move to 2.16, although not much has changed in this specific area
AFAIK.

Since camel-jms is using a single replymanager/listener for the
responses the selector is or'ing replies like:
Using MessageSelector[JMSCorrelationID='ID:c1d4d840d3c6c9d9404040404040404056232fb22027853e'
OR JMSCorrelationID='ID:c1d4d840d3c6c9d9404040404040404056232fb220278c74']

Is there any way to go around this in configuration so that a distinct
session would be used for each request/response pair with a selector
for one single correlationId (and hence shouldn't be much of a
performance overhead in respect to session/consumer allocation -
especially not when underlying connections are pooled etc)

Looking at sjms as an alternative I get mixed messages (pun intended),
as it states:

"When using InOut with SJMS in a clustered environment you must either
use TemporaryQueue destinations or use a unique named reply to
destination per InOut producer endpoint...."

but also "Currently the only correlation strategy is to use the
JMSCorrelationId. The InOut Consumer uses this strategy as well
ensuring that all responses messages to the included JMSReplyTo
destination also have the JMSCorrelationId copied from the request as
well."

as long as using messageId and correlationId there should be no
problem sharing a queue for replies.

[1] http://www-01.ibm.com/support/docview.wss?uid=swg21170345
[2] https://www-01.ibm.com/support/knowledgecenter/SSFKSJ_8.0.0/com.ibm.mq.dev.doc/q023000_.htm?lang=en
(see chapter "Messaging Performance").



--
--
David J. M. Karlsen - http://www.linkedin.com/in/davidkarlsen


-- 
--
David J. M. Karlsen - http://www.linkedin.com/in/davidkarlsen