Yes the async routing engine requires that threads are not being blocked etc, and not all Camel components / 3rd party libraries can support that.
On Fri, Sep 26, 2014 at 3:27 AM, Andrew Thorburn <[email protected]> wrote: > I'd be happy to update the docs, though I've haven't signed the agreement > yet. Can I take it that I understand what's going on correctly, regarding > the asyncConsumer option? > > Thanks, > > - Andrew > > On Thu, Sep 25, 2014 at 7:35 PM, Claus Ibsen <[email protected]> wrote: > >> Hi >> >> You are welcome to improve the docs, eg add some details about this to >> the asyncConsumer option. >> http://camel.apache.org/jms >> >> Though maybe its best placed be on the async routing engine page, as >> it applies to how it works and under which circumstances. >> http://camel.apache.org/asynchronous-routing-engine.html >> >> And then you can refer to this page from the jms page, for more details. >> >> And lets keep the option name as is, as this is the naming convention >> used by Camel and in the source code as well. >> >> We love contributions >> http://camel.apache.org/contributing.html >> >> And here is how to help edit the docs >> http://camel.apache.org/how-do-i-edit-the-website.html >> >> On Thu, Sep 25, 2014 at 4:07 AM, Andrew Thorburn <[email protected]> wrote: >> > 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 >> >> >> >> -- >> Claus Ibsen >> ----------------- >> Red Hat, Inc. >> Email: [email protected] >> Twitter: davsclaus >> Blog: http://davsclaus.com >> Author of Camel in Action: http://www.manning.com/ibsen >> hawtio: http://hawt.io/ >> fabric8: http://fabric8.io/ >> -- Claus Ibsen ----------------- Red Hat, Inc. Email: [email protected] Twitter: davsclaus Blog: http://davsclaus.com Author of Camel in Action: http://www.manning.com/ibsen hawtio: http://hawt.io/ fabric8: http://fabric8.io/
