The Channel concept really makes a lot of sense. This will certainly make
Camel concepts fit more closely with the EIP book (channels are used in
between everything), and hopefully make Camel easier to understand as a
result.

I agree, the async backbone of Camel is in need for an overhaul. Though, I'm
a bit worried of breaking existing folks stuff that depends on the current
async code, no matter how hard to understand it is. Like Willem said, I
think we need to ensure the UnitOfWork stuff fits the bill before ditching
the AsyncProcessor.

On Fri, Apr 24, 2009 at 2:51 AM, Claus Ibsen <claus.ib...@gmail.com> wrote:

> Hi Camel riders
>
> As you know we are working on Camel 2.0 and we decided to do a 2nd
> milestone release.
> This gives us more time to start on some of the ideas and internal
> refactorings I wanted
> to do for Camel 2.1.
>
> After having dived really deed in the camel core codebase for the last
> 6+ months or longer, I
> feel that we need to cease the moment and do a more extensive house
> cleaning before the Camel 2.0
> release. The house cleaning is only internal and will not affect end
> users of Camel.
>
> Here are 2 issues I would like to address in the foreseeable future.
>
>
> 1) Channel
> ==========
> To introduce a Channel between each node in the route path. The
> channel is a composite processor
> that is responsible for routing the exchange to the next node in the path.
>
> We already do this but there is no visible notion of a Channel. The
> "Channel" exists today as
> a series of interceptors and an error handler. Today this is wrapped
> at route build time
> and then we have a static list of processors the exchanges is routed
> through a runtime.
>
> So what I am working on is to composite this series of interceptors
> and error handler into a
> DefaultChannel class that has the logic to do needed work before an
> Exchange is routed to the next
> node.
>
> I have already discussed this a bit with Gert and James. James agreed
> that it a was time for introducing
> the Channel into Camel.
>
> So I have started experimenting with this and got it working locally.
> The Channel is in this first
> stage just wrapping the existing series of interceptors and error
> handler and thus the route logic
> is not affect.
>
> In the future the Channel will benefit in many ways as we can at
> runtime add routing logic for instance
> - enabling/disabling tracing (and other interceptors) at runtime
> without reloading routes
> - adding or removing interceptors at runtime without reloading routes
> - adding or removing JMX performance metrics at runtime without reloading
> routes
> - we could use it to blocking routing
> - enhanced tooling support
> - potential you could persist exchanges at the channel
> - later add true async processing with the help of the channel
> - easier to traverse the runtime route graph as we can traverse the
> Channel, where we can have next/prev or the like methods
> - and much more we can imagine
>
>
>
> 2) AsyncProcessor
> =================
> I propose to remove the AsyncProcessor all together. I had a chat with
> James about it and it was an experiment by Hiram back in early 2007.
> Basically he had not worked on the code since, and its not really put
> into good use. But sadly over time the AsyncProcessor have spread
> itself into other core parts of Camel.
>
> The basic idea was to attach a callback to a route so you could do
> some "commit" work after the exchange is finished.
> This idea is actually superseded by the UnitOfWork (introduced by
> James) that is better for this kind of work. And we have schduled an
> overhaul for UnitOfWork
> in Camel 2.1 to allow more of our components to take advantage of this
> and also expose DSLs for end users to attach their custom processors
> or route.
>
> The code in Camel core that is affected by the AsyncProcessor is much
> more complex than regular Processor. In fact there are some areas
> where its not
> used correctly and causes unforseen side effects that only surfaces in
> some complex or rare unit tests. This issues is more apparent lately
> as more
> and more camel processors supports the async processor directly.
>
> The original code by Hiram only leverages the async callback in the
> file component as it was part of his initial code. No other areas
> benefits from this.
> The code is basically making it bloat and complex inside Camel itself.
>
> End users do not use this. I do not recall a single question on it in
> the user forum.
>
> So I am in a big +1 to get it out of the codebase.
>
> And before you say well how do we do async routing then? Well the seda
> component is still there to truely spawn a new thread to route an
> exchange.
> And we have the UnitOfWork where you are supposed to register your
> callback. We might make the UnitOfWork a bit easier to register
> callbacks for
> only commit or failure depending on what you want. If its a single
> methods its also easier for dynamic languages to have nice DSL support
> for it.
> Well that is just me rambling now..... And the UnitOfWork was James
> envision for doing async work after the exchange is ended.
>
>
> Summary
> =======
>
> 1) Channel
> The first cut of this is already done on my local laptop and it will
> just work as is today. But its bases the foundation for more exotic
> and advanced
> stuff in Camel 2.x series.
>
> Already in progress.
>
> Any thoughts?
>
>
> 2) AsyncProcessor
> To reduce the complexity for maintaining the Camel codebase. Just as
> Gert if he was a bit puzzled how to do his StreamCache that uses the
> Async stuff.
> When we get it out of there the codebase is much easier to maintain
> and we have a greater chance to attract potential new committers.
>
> I vote +1 for this.
> 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
>



-- 
Cheers,
Jon

http://janstey.blogspot.com/

Reply via email to