Hey guys, Just want to clarify that I understand how this works correctly:
Setting the "asyncConsumer" option to "true" on a JMS Consumer does not, in and of itself, mean that messages are guaranteed to be processed asynchronously, but it does mean that if an endpoint supports asynchronous behaviour, the Camel JMS consumer will allow that. In other words, if you set "asyncConsumer" to "true", but none of your endpoints in your pipeline allow asynchronous processing, it will all get processed synchronously anyway. In that case, you would need to wrap everything you wanted processed asynchronously in a <threads> tag (or a threads() call), which would allow you to control the number of threads, the queue size, etc. Conversely, even if you provide a <threads> wrapper, if asyncConsumer is set to "false", it will get processed synchronously. Is that correct? It appears to be, based on what I can see in the source code (looking at Threads, JMS Configuration, JMS Consumer, EndpointMessageListener, etc). If that's correct, wouldn't it make sense to rename the option asyncConsumer to asyncAllowed (or maybe asyncConsumerAllowed)? asyncConsumer implies, at least to me, that the consumer will somehow magically run everything asynchronously without the need for further configuration, when that does not appear to be true. asyncAllowed is closer to what actually happens - in that setting the option does not magically make everything asynchronous, but if you *want* to make it asynchronous yourself, you can. Also, this implies that the example at the bottom of http://camel.apache.org/async.html is, if not wrong, then at least missing information, as it does not show that the JMS consumer has had the "asyncConsumer" option set on it anywhere. FWIW, as I'm integrating with WebSphere MQ, and the queue I'm consuming from is set to EXCLUSIVE_OPEN (or something along those lines), I don't believe that I can make any use of the concurrentConsumers/maxConcurrentConsumers options on the JMS endpoint. Thanks, - Andrew Thorburn
