Hi
This is just a short update on:
Ad 3)
The new Async API
I started iTunes with some good tunes from my youth gone wild period,
so I had a crack at prototype of the async API.
Here is the first unit test demonstrating how it could work with the
JDK Future API (for real async)
public class DefaultAsyncProcessorTemplateTest extends ContextTestSupport {
public void testRequestAsync() throws Exception {
AsyncProducerTemplate async = new DefaultAsyncProducerTemplate(context);
async.start();
Exchange exchange = new DefaultExchange(context);
exchange.getIn().setBody("Hello");
Future<Exchange> future = async.requestAsync("direct:start", exchange);
long start = System.currentTimeMillis();
System.out.println("Look ma I can do other stuff while the async runs");
Exchange result = future.get();
long delta = System.currentTimeMillis() - start;
System.out.println("Damn that async takes time so I had to
wait " + delta + " ms.");
assertEquals("Hello World", result.getOut().getBody());
async.stop();
}
@Override
protected RouteBuilder createRouteBuilder() throws Exception {
return new RouteBuilder() {
@Override
public void configure() throws Exception {
from("direct:start")
.delay(2000)
.transform(body().append(" World")).to("mock:result");
}
};
}
}
And the console ouput when I run it
2009-04-30 10:43:56,585 [main ] INFO DefaultCamelContext
- Apache Camel (CamelContext:camel-1) started
2009-04-30 10:43:56,586 [main ] DEBUG
aultAsyncProcessorTemplateTest - Routing Rules are: ....
Look ma I can do other stuff while the async runs
2009-04-30 10:43:58,833 [pool-1-thread-1] DEBUG MockEndpoint
- mock:result >>>> 1 : Exchange[Message: Hello World] with
body: Hello World
Damn that async takes time so I had to wait 2134 ms.
2009-04-30 10:43:58,835 [main ] DEBUG
aultAsyncProcessorTemplateTest - tearDown test: testRequestAsync
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
