Dear Camel developers, we've been happily using the camel provided jms component to interface with Tibco EMS 4 and 5 as well as with WebSphere MQ 6. While we had no problems with the InOnly routes, we ran into issues with the InOut:
1) When using the InOut MEP we noticed that the performance was bound by the setting of the receive timeout of the underlying JmsEndpoint. Looking closer we saw that Camel uses a single message listener (container) on the reply queue with a MessageSelectorComposer (PersistentReplyToRequestor.CamelDefaultMessageListenerContainer) to which the correlation id's of the expected replies are being added and removed. Because it starts off with a random id and immediately goes into a timed receive loop of 1000ms by default, the expected correlation id is always added after the request was sent giving us a consistent 1sec performance for InOut exchanges. Lowering the receive timeout made it perform a bit better but also blew up on one host with Tibco EMS and a receive timeout of 10ms where it started to miss all replies (we didn't drill down on this). 2) When using IBM MQ and Camel's composite message selector on the reply queue (id=randomId OR id=correlId1 or id=correlId2 ...) as described above, we witnessed an even more dramatic performance degradation which correlated with the amount of messages already lying on the reply queue. This is because the JMS message selectors in the WebSphereMQ's jms drivers are only optimized for a single JMSCorrelationID. When using a composite selector, it reverts to fetching all message from the queue each time in order to the check them in sequence against the provided selector: http://www-01.ibm.com/support/docview.wss?uid=swg21170345 Given these problems with JMS InOut processing, the only viable solution for us was to use a completely different approach to the InOut handling by letting the requesting thread perform a timed receive (with requestTimeout ms) for a single correlation id, thus completely bypassing the current InOut mechanism provided by the PersistentReplyToRequestor. We've currently only "hacked" it by overriding the JmsProducer's processInOut method and are using an additional JmsTemplate to do this timed receive for a single reply after submitting the request and it works well and much faster for both EMS and MQ (we also don't need temporary destinations). We do think that the camel-jms component should provide this reply correlation mechanism in the context of the calling thread out of the box and are hence suggesting this as a future enhancement. What do you think? Regards, Oliver Deak -- View this message in context: http://old.nabble.com/Camel-JMS-InOut-Performance-Issues-with-Correlation-Mechanism-tp27405612p27405612.html Sent from the Camel Development mailing list archive at Nabble.com.
