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