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 claus.ibsen@gmail.com
 designates 209.85.213.175 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAGfr3_mAZ0pmC38vFED2pmUqffCyx3FehjnqM+J=eQ6c8yY7xw@mail.gmail.com>
References: <1388508988485-5745385.post@n5.nabble.com>
	<1388867928057-5745542.post@n5.nabble.com>
	<CAGB5yN=j0sCoUHynU_pAMW9ciw7RYxAk08rzKRc6UmrUsM8zMA@mail.gmail.com>
	<CAGfr3_mAZ0pmC38vFED2pmUqffCyx3FehjnqM+J=eQ6c8yY7xw@mail.gmail.com>
Date: Sun, 5 Jan 2014 18:02:00 +0100
Message-ID: 
 <CAGB5yNnCd4se+jP0gpgVo+fwHbKKrf+c24o76Hi6r8iUQ+ih2g@mail.gmail.com>
Subject: Re: Asynchronous processing of routes
From: Claus Ibsen <claus.ibsen@gmail.com>
To: "users@camel.apache.org" <users@camel.apache.org>
Content-Type: multipart/alternative; boundary=20cf302234d50a048c04ef3c1a4c

--20cf302234d50a048c04ef3c1a4c
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Just enable asyncConsumer=3Dtrue

s=F8ndag den 5. januar 2014 skrev kraythe . :

> 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 on=
ly
> 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 throug=
h
> 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 sl=
ip
> and sends the message off to that slip.
>
> Through these techniques the only routes that need be synchronous are tho=
se
> 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<javasc=
ript:;>>
> 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 =3D 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 =3D bar
> >   to Z2
> >
> > from X3
> >   to jms foo ? replyTo =3D bar
> >   to Z3
> >
> >
> >
> >
> > On Sat, Jan 4, 2014 at 9:38 PM, yashgt <yashgt@gmail.com <javascript:;>=
>
> wrote:
> > > Perhaps my post was not clear enough...
> > >
> > > Route 1 send M1 to the target service over MQ1 and waits for the targ=
et
> > 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-tp574=
5385p5745542.html
> > > Sent from the Camel - Users mailing list archive at Nabble.com.
> >
> >
> >
> > --
> > Claus Ibsen
> > -----------------
> > Red Hat, Inc.
> > Email: cibsen@redhat.com <javascript:;>
> > 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
> >
>


--=20
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

--20cf302234d50a048c04ef3c1a4c--