Mailing-List: contact users-help@camel.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@camel.apache.org
Received-SPF: pass (athena.apache.org: domain of kraythe@gmail.com designates
 209.85.128.182 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAGB5yN=j0sCoUHynU_pAMW9ciw7RYxAk08rzKRc6UmrUsM8zMA@mail.gmail.com>
References: <1388508988485-5745385.post@n5.nabble.com>
	<1388867928057-5745542.post@n5.nabble.com>
	<CAGB5yN=j0sCoUHynU_pAMW9ciw7RYxAk08rzKRc6UmrUsM8zMA@mail.gmail.com>
Date: Sun, 5 Jan 2014 10:24:13 -0600
Message-ID: 
 <CAGfr3_mAZ0pmC38vFED2pmUqffCyx3FehjnqM+J=eQ6c8yY7xw@mail.gmail.com>
Subject: Re: Asynchronous processing of routes
From: "kraythe ." <kraythe@gmail.com>
To: Camel Users List <users@camel.apache.org>
Content-Type: multipart/alternative; boundary=001a1136bccee60e4d04ef3b92ee

--001a1136bccee60e4d04ef3b92ee
Content-Type: text/plain; charset=ISO-8859-1

The interesting thing is that you don't have to do synchronous request
reply to have a route processing flow with a defined order. Consider a
route like the following:

from("jms:queue:input").to("jms:queue:processA").to("jms:queue:processB").to("jms:queue:results")

And the helper routes:

from("jms:queue:processA").to("bean:A")
from("jms:queue:processB").to("bean:B")

This is a synchronous mindset and suffers from a number of issues in
scalability. The route calls each sub process through JMS and then waits
for the response. However, one message that takes a long time to process
holds up the entire route for all inputs. Furthermore, if process A takes a
long time but process B is quick, your ability to federate the route is
bottlenecked. Contrast that with the following.

from("jms:queue:input").to("jms:queue:processA")
from("jms:queue:processA").to("bean:A").to("jms:queue:processB")
from("jms:queue:processB").to("bean:B").to("jms:queue:results")

This is much more scalable. You can run 20 routes of type processA and only
2 of process B. That allows messages to flow through asynchronously. This
is a powerful technique but requires you to divorce your mind from
input-output synchronous techniques. However it can be even better through
the use of an asynchronous routing slip. The initial route sets the flow
and stores it as a list of endpoints in a header. As the message flows
through, each route pops the next item off the stack that makes up the slip
and sends the message off to that slip.

Through these techniques the only routes that need be synchronous are those
where users are waiting for responses (such as RESTlet) and even those
routes can call synchronous routes.

Camel should open your mind to new posibilites.

*Robert Simmons Jr. MSc. - Lead Java Architect @ EA*
*Author of: Hardcore Java (2003) and Maintainable Java (2012)*
*LinkedIn: **http://www.linkedin.com/pub/robert-simmons/40/852/a39
<http://www.linkedin.com/pub/robert-simmons/40/852/a39>*


On Sun, Jan 5, 2014 at 2:27 AM, Claus Ibsen <claus.ibsen@gmail.com> wrote:

> Hi
>
> If you do request/reply over JMS in a Camel route then it correlates
> and waits for the expected reply message.
>
> So you can do
>
> from X
>   to jms foo ? replyTo = bar
>   to Z
>
> Where the jms endpoint is doing request/reply over JMS
>
> And you can have multiple routes doing request/reply over JMS as well,
> and also use shared/exclusive queues etc
> Read more about this on the JMS page at: http://camel.apache.org/jms
>
> from X2
>   to jms foo ? replyTo = bar
>   to Z2
>
> from X3
>   to jms foo ? replyTo = bar
>   to Z3
>
>
>
>
> On Sat, Jan 4, 2014 at 9:38 PM, yashgt <yashgt@gmail.com> wrote:
> > Perhaps my post was not clear enough...
> >
> > Route 1 send M1 to the target service over MQ1 and waits for the target
> to
> > respond back with message M2 on MQ2.
> >
> > Now, like Route1, there are many other routes that expect different
> > messages.
> >
> > RouteX expects MX to come on MQ2. RouteY expects MY to come on MQ2.
> >
> > The solutions so far indicate that I should keep consuming from MQ2 till
> I
> > get M2 and then proceed with Route1. This means the RouteX and RouteY
> will
> > never get the messages as they have been consumed by Route1.
> >
> >
> >
> >
> >
> > --
> > View this message in context:
> http://camel.465427.n5.nabble.com/Asynchronous-processing-of-routes-tp5745385p5745542.html
> > Sent from the Camel - Users mailing list archive at Nabble.com.
>
>
>
> --
> Claus Ibsen
> -----------------
> Red Hat, Inc.
> Email: cibsen@redhat.com
> Twitter: davsclaus
> Blog: http://davsclaus.com
> Author of Camel in Action: http://www.manning.com/ibsen
> Make your Camel applications look hawt, try: http://hawt.io
>

--001a1136bccee60e4d04ef3b92ee--