Mailing-List: contact dev-help@camel.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@camel.apache.org
Received-SPF: pass (nike.apache.org: domain of janstey@gmail.com designates
 209.85.218.178 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type;
        b=MykeTunbmFMiYCCviLD7YkDF33G02UqbCsr2gTVuRX8Ow/LlDGDZzd8NtlYXw2XCLp
         ovEBleQPmH9ZjOEVgXFJx3bFsezvJbhVGmc+6UH4hyERU0hxrHiAIXul4QEDWa/3qu7R
         yJKtjVcOPwC4g2+DiufxkVVqYGrbZTmlM+xH0=
MIME-Version: 1.0
In-Reply-To: <5380c69c0904232221w7cb61ab3jb911b91ebbb643c1@mail.gmail.com>
References: <5380c69c0904232221w7cb61ab3jb911b91ebbb643c1@mail.gmail.com>
Date: Fri, 24 Apr 2009 10:16:47 -0230
Message-ID: <2748945d0904240546k57539f7cjbcbb262ce73195fd@mail.gmail.com>
Subject: Re: [DISCUSS - Camel 2.0 - Internal API reworkings] - Channel and
	AsyncProcessor
From: Jon Anstey <janstey@gmail.com>
To: dev@camel.apache.org
Content-Type: multipart/alternative; boundary=00504502b630c7e41204684c632f

--00504502b630c7e41204684c632f
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

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.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?
>
>
>
>
> --
> 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/

--00504502b630c7e41204684c632f--