Hi I have created a ticket to track this https://issues.apache.org/activemq/browse/CAMEL-1572
And I have attached a patch to address item #1, #2 and #4. All unit tests passes (core, components, tests, etc.) On Thu, Apr 30, 2009 at 7:32 AM, Claus Ibsen <claus.ib...@gmail.com> wrote: > Hi > > You might remember my previous topic about the AsyncProcessor. > http://www.nabble.com/-DISCUSS---Camel-2.0---Internal-API-reworkings----Channel-and--AsyncProcessor-td23210093.html > > > I had some more time to thinker about it and I believe I have a > roadmap for a solution that will work nicely for all. > > 1) Internal house cleaning in camel-core > 2) Fix as much of the current broken AsyncCallback > 3) Introduce new async API in Camel 2.0 > 4) Mark the current AsyncCallback as @deprecated in Camel 2.0m2 > > > Ad 1) > The AsyncProcessing internally in Camel is overused and it just makes > it much more complex. By doing a house cleaning the codebase is much > easier to work with and it works as before. > In fact it allows us to do fix the broken AsyncCallback also so we can > get notification when the async exchange is done. > > > Ad 2) > The current notification in Camel is in fact broken. You never get the > expected notification when the async exchange is done. The idea of > this API was to get 2 notifications > - the 1st is when the original synch thread is done (the boolean is > true), eg when you submit the job. > - and then the 2nd when the async thread is done (the boolean is > false) but this is broken in Camel and you will not receive it. > > And of top of this there are 2 flaws in the current API > - the current code requires that you manaully add seda steps in the > route to turn the route from sync into async. There was no code that > did this "under the covers for you". However its doable and the in > fact its possible to route async. But an improve API would be better. > - The result of the async operation is not possible to get easily. No > you dont have access to the exchange that was done async. And no > exchange.getOut() will not give the result. What was missing in the > AsyncCallback API was to pass in the Exchange as well. > > > Ad 3) > I would like to introduce a new Async API that is more similar to the > JDK Future API. So you can use the Future get() to get hold of the > result. > This still needs some thinking and experimenting to see how its > doable. But an API that generally is like the Future would be much > better. > > Ad 4) > I would also suggest that we (in Camel 2.0m2) mark AsyncCallback as > @deprecated with a note that we have planned a new Async API for Camel > 2.0 > > > Conclusion > ======== > I would like to go forward and get #1, (#2 and #4 would be great too) > committed into the codebase so we have a codebase in Camel that is > much easier to maintain and for new users to understand when they look > into the internals in Camel. And especially debugging and stepping > through the processing of Exchanges is much easier. As its just > regular method calls. And we get rid of the confusing code with what > to do in the AsyncCallbacks that was invading the internals in Camel. > > > Then I would start experimenting with the new API and report findings. > Feedback here is much welcome. > > > Any thoughts? > > > -- > Claus Ibsen > Apache Camel Committer > > Open Source Integration: http://fusesource.com > Blog: http://davsclaus.blogspot.com/ > Twitter: http://twitter.com/davsclaus > Apache Camel Reference Card: > http://refcardz.dzone.com/refcardz/enterprise-integration > -- Claus Ibsen Apache Camel Committer Open Source Integration: http://fusesource.com Blog: http://davsclaus.blogspot.com/ Twitter: http://twitter.com/davsclaus Apache Camel Reference Card: http://refcardz.dzone.com/refcardz/enterprise-integration
