camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Claus Ibsen <claus.ib...@gmail.com>
Subject Re: Asynchronous processing of routes
Date Sun, 05 Jan 2014 17:02:00 GMT
Just enable asyncConsumer=true

s√łndag 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 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<javascript:;>>
> 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 <javascript:;>>
> 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 <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
> >
>


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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message