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 claus.ibsen@gmail.com
 designates 209.85.161.45 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:from:date:message-id:subject:to
         :content-type;
        b=GM9DVGbRIzIbupF+re2f3GabafrBA0DCB6uIrzAt2BxnNLdV3c+JHxb4M7KKOklDXo
         TIeHgly8blEy8r68fErW/vnutc8HMb08ohh0PblHmWr2ahOPCn1sZWD0Q8sCY2zRxhce
         Nty4demm+CiU1RDa2gIy8Npi/9mGQgGGBGVGs=
MIME-Version: 1.0
In-Reply-To: <AANLkTimk0lCm4MYL4nod99CCBCRLuzhhGLuUAwAA5bVk@mail.gmail.com>
References: <AANLkTikaXRcEwl4CuHW5zradJfdqSlgSRVdNfnKJzEsI@mail.gmail.com>
	<AANLkTimk0lCm4MYL4nod99CCBCRLuzhhGLuUAwAA5bVk@mail.gmail.com>
From: Claus Ibsen <claus.ibsen@gmail.com>
Date: Fri, 2 Jul 2010 15:47:29 +0200
Message-ID: <AANLkTimVWoGAxxQA0YA6qmJaZJ0-MuBaFaOboYzqHj91@mail.gmail.com>
Subject: Re: Asynchronous Routing Engine - Status
To: dev@camel.apache.org
Content-Type: text/plain; charset=ISO-8859-1

On Fri, Jul 2, 2010 at 3:33 PM, Claus Ibsen <claus.ibsen@gmail.com> wrote:
> Hi
>
> Just to update the status that today I have implemented
>
> a) error handler will now schedule delayed redeliveries by default
> which thus allows to not block while the delay occurs. You can disable
> this behavior using the syncDelayed() option on the error handler /
> onException / routePolicy. And if you use transactions it will use
> synced delays to ensure the exchange will use the same thread again as
> the Transaction Manager requires to execute in the same thread
> context.
>

Just a though.

Do anyone think it would be best to keep the old behavior as default?
To block while delaying when routing synchronous?

For a single consumer thread this could cause it to be able to pickup
new messages which might also fail
and thus stack up messages on the delayed redelivery task queue?

I think I will flip back the default so it works as it have always
done, then people can turn this option on to have async delayed if
they want.


> b) delay and throttle EIP now have an option asyncDelayed() you can
> use to enable them to use non blocking delay as well
>
> The only question though would be if we should have an option to allow
> you to cancel tasks on shutdown. If you have messages queued up in the
> delay/throttle. Then a fast stop to cancel the pending tasks is
> possible. However the JDK ExecutorService API is damn poor in terms of
> stopping the thread pool. You can only shut it down which then cant
> restart it. And getting the pending tasks is also not possible unless
> you gather the Future references and then remember to keep this list
> up to date removing the done tasks.
>
>
> On Thu, Jul 1, 2010 at 1:58 PM, Claus Ibsen <claus.ibsen@gmail.com> wrote:
>> Hi
>>
>> The major goal for Camel 2.4 is introducing back the asynchronous
>> routing engine from the Camel 1.x days.
>> What we had replaced it with, just didn't cut it for the long run, so
>> we had to toss it out and replace it back with the 1.x variation.
>> However the 1.x variation is much more invasive in the camel core.
>> However the benefits are worth it.
>>
>> There is a JIRA ticket to track this
>> https://issues.apache.org/activemq/browse/CAMEL-2723
>>
>> We got so far with the code that we can move ahead the release
>> schedule for 2.4 and thus why Hadrian send out
>> an announcement yesterday.
>>
>> The engine has been integrated with Apache ServiceMix JBI and NMR,
>> which means that in SMX 4.3 and Came. 2.4 onwards
>> you have much better scalability and utilization of the resources.
>>
>> There is present only a single Camel component which leverages the
>> async routing as well which is Jetty.
>> The consumer side uses Jetty continuations and the producer side the
>> Jetty http async client.
>>
>> We plan to expand this to other Camel components where async
>> communication is native supported by the component.
>> Such as Netty, Mina 2 (when its out), CXF producer, REST stuff and what else.
>>
>> Mind that async routing does not work to the fullest if you are not
>> using transactions. Spring TM requires the transactional resources to
>> be
>> executed from the same thread context, which is why Camel will
>> fallback to route fully synchronous if you use transacted routes.
>> This works automatic and you dont have to worry about it to configure
>> any of the Camel endpoints to cater for this. It's just that Camel
>> will have the caller thread blocked while waiting for the async reply,
>> in case you for example to request/reply over NMR in a transaction.
>>
>>
>> Almost all the EIP patterns in Camel have been refactored to support
>> async routing engine as well. So you can use Splitter, Recipient List,
>> WireTap
>> and all the others in the most optimal way. Currently there are 3
>> outstanding works to be looked at:
>> - Throttler and Delayer EIP to not block while waiting
>> - Multicast, Recipient List and Splitter EIP to support async routing
>> engine when parallelProcessing option is enabled (this is a bit tricky
>> to do).
>> - RedeliverErrorHandler to use non blocking while waiting for delivery
>> (current only enabled if async routing has been kicked in) but we can
>> do this in a general.
>>
>>
>>
>>
>> --
>> Claus Ibsen
>> Apache Camel Committer
>>
>> Author of Camel in Action: http://www.manning.com/ibsen/
>> Open Source Integration: http://fusesource.com
>> Blog: http://davsclaus.blogspot.com/
>> Twitter: http://twitter.com/davsclaus
>>
>
>
>
> --
> Claus Ibsen
> Apache Camel Committer
>
> Author of Camel in Action: http://www.manning.com/ibsen/
> Open Source Integration: http://fusesource.com
> Blog: http://davsclaus.blogspot.com/
> Twitter: http://twitter.com/davsclaus
>


-- 
Claus Ibsen
Apache Camel Committer

Author of Camel in Action: http://www.manning.com/ibsen/
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Twitter: http://twitter.com/davsclaus