It's been a while since I looked at this code. I would verify that your changes will not break local transaction support. I suspect that this could be an issue if you were to simply block the producer with a timed receive call.
There is a bunch of tests in Camel unit tests. Are they all passing? Thanks, Marat On Mon, Feb 1, 2010 at 10:03 AM, Oliver Deak <o...@ztec.ch> wrote: > > 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. > >
