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
