By the way, Consider using a second strategy of picking up replies from a shared queue by using replyToDestinationSelectorName property. The idea that each producer has a unique value for a named property on which you select reply messages on. The the reply consumer will collect all reply messages that match that unique value, thus getting only the reply messages destined to this producer.
http://issues.apache.org/activemq/browse/CAMEL-490 Thanks, Marat On Mon, Feb 1, 2010 at 1:46 PM, Marat Bedretdinov < marat.bedretdi...@gmail.com> wrote: > 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. >> >> >
