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/
