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/ >
