camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bruce Snyder <bruce.sny...@gmail.com>
Subject Re: [DISCUSS - Camel 2.0 - Internal API reworkings] - Channel and AsyncProcessor
Date Fri, 24 Apr 2009 19:17:49 GMT
On Thu, Apr 23, 2009 at 11:21 PM, Claus Ibsen <claus.ibsen@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?

+1 for adding the Channel, excellent idea. This will obviously allow
for many great features including the asynchronous exchanges. But I
wouldn't advocate removing the current async support (even if it is
broken) without putting a proper solution in its place. We don't want
to inadvertently break user's code.

IMO, if better async support is going to be added, then the 2.0
release is the perfect place for it to be introduced as a new feature
set. Users expect big new functionality in a major release, not a
minor one. Of course adding full asynchronous support will take time
(i.e., *full* testing and examples are time consuming); and I think
users deserve full examples and explanations. Some of the partial and
incomplete examples in the docs seem to generate much confusion.

BTW, I'm interested to help out if any assistance is needed.

Bruce
-- 
perl -e 'print unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
);'

ActiveMQ in Action: http://bit.ly/2je6cQ
Blog: http://bruceblog.org/
Twitter: http://twitter.com/brucesnyder

Mime
View raw message