Re: multicast aggregation
What version of Camel do you use?
On Mon, Jan 6, 2014 at 12:03 AM, Minh Tran wrote:
> Hi all
>
> I'm currently using multicast in my route with an aggregation strategy and
> I'm finding that if my multicast only has one route defined in it, then my
> aggregation strategy is never called. Is this expected behaviour? I would
> have expected the first call to the aggregation strategy to occur with the
> newExchange being null.
>
> eg
> … multicast(myStrategy).to("direct:foo", "direct:bar").end()
> myStrategy is called, however
>
> … multicast(myStrategy).to("direct:foo").end()
> myStrategy is never called
>
> Admittedly there's no point having a multicast if it only goes to one route
> but I am putting this in place because I am expecting to add extra routes in
> the future to the multicast.
>
> Thanks
>
--
Claus Ibsen
-
Red Hat, Inc.
Email: cib...@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
Extract values from header in xpath in Spring DSL
Consider this xml : Harry Potter J K. Rowling 2005 29.99 Learning XML Erik T. Ray 2003 39.95 I have a set header the header after splitter as /bookstore/book Now after performing a few operations I want to find if the category in the header TEST is CHILDREN, what should the following xpath be? *$in.header.TEST*/book/@category= 'CHILDREN' Perform some operation I am using camel 2.0.9, so I if I use headerName in xpath, it throws error. Kindly suggest what the xpath should be? - Satyam A Maloo -- View this message in context: http://camel.465427.n5.nabble.com/Extract-values-from-header-in-xpath-in-Spring-DSL-tp5745599.html Sent from the Camel - Users mailing list archive at Nabble.com.
Re: How can I call a web service with no parameters via a producerTemplate?
Please any one suggest solution for my problem. -- View this message in context: http://camel.465427.n5.nabble.com/How-can-I-call-a-web-service-with-no-parameters-via-a-producerTemplate-tp4806257p5745580.html Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Asynchronous processing of routes
Correct me if I am wrong. Camel will correlate the response if the other service sends back the response with the same correlation ID as was sent to it in the Request. If the other service is not using Camel and is solely reading messages directly from MQ, it will not have the knowledge of where to find the correlation ID in the Request and where to put it in the Response. In our case, the other services are third-party C++ services which work directly with MQ and do not use Camel. -- View this message in context: http://camel.465427.n5.nabble.com/Asynchronous-processing-of-routes-tp5745385p5745565.html Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Asynchronous processing of routes
In my case, there may be multiple routes running in parallel. But I do not want to have multiple instances of the same route. All I need is a way by which a route will stop midway and wait for a MQ message to arrive as a response. I know from your responses that this is possible if the responder fills the right correlation ID. But in my case the responder does not fill the correlation ID. Thanks, Yash -- View this message in context: http://camel.465427.n5.nabble.com/Asynchronous-processing-of-routes-tp5745385p5745569.html Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Is there a way to debug in Eclipse Groovy scripts in Camel-Language component?
Hi, I’m not sure if you can debug the Groovy scripts with CamelContext in Eclipse. But I think you can debug the scripts by using Groovy Eclipse plugin. -- Willem Jiang Red Hat, Inc. Web: http://www.redhat.com Blog: http://willemjiang.blogspot.com(http://willemjiang.blogspot.com/) (English) http://jnn.iteye.com(http://jnn.javaeye.com/) (Chinese) Twitter: willemjiang Weibo: 姜宁willem On January 6, 2014 at 6:58:11 AM, bocamel (johnz...@gmail.com) wrote: > > Using groovy scripts in Camel Language component > (uri="language://groovy:resource:classpath:x.groovy") > turned out to be a > very powerful and flexible way to add business logic into a production > Camel > route. One can do just about anything in the groovy scripts without > having > to rebuild the application. But such scripts cannot be debugged > easily in > Eclipse, it seems. Does anyone know a way to step through such > groovy > scripts in Eclipse? Thanks for any help! > > > > -- > View this message in context: > http://camel.465427.n5.nabble.com/Is-there-a-way-to-debug-in-Eclipse-Groovy-scripts-in-Camel-Language-component-tp5745570.html > > Sent from the Camel - Users mailing list archive at Nabble.com. >
multicast aggregation
Hi all
I'm currently using multicast in my route with an aggregation strategy and I'm
finding that if my multicast only has one route defined in it, then my
aggregation strategy is never called. Is this expected behaviour? I would have
expected the first call to the aggregation strategy to occur with the
newExchange being null.
eg
… multicast(myStrategy).to("direct:foo", "direct:bar").end()
myStrategy is called, however
… multicast(myStrategy).to("direct:foo").end()
myStrategy is never called
Admittedly there's no point having a multicast if it only goes to one route but
I am putting this in place because I am expecting to add extra routes in the
future to the multicast.
Thanks
Is there a way to debug in Eclipse Groovy scripts in Camel-Language component?
Using groovy scripts in Camel Language component (uri="language://groovy:resource:classpath:x.groovy") turned out to be a very powerful and flexible way to add business logic into a production Camel route. One can do just about anything in the groovy scripts without having to rebuild the application. But such scripts cannot be debugged easily in Eclipse, it seems. Does anyone know a way to step through such groovy scripts in Eclipse? Thanks for any help! -- View this message in context: http://camel.465427.n5.nabble.com/Is-there-a-way-to-debug-in-Eclipse-Groovy-scripts-in-Camel-Language-component-tp5745570.html Sent from the Camel - Users mailing list archive at Nabble.com.
Why does ConsumerTemplate.receiveBody receive more than one message at a time from SEDA queue?
When using a consumer template to receive messages from seda queue, a single
receiveBody (or receiveBodyNoWait) seems to consume more than one message
from the queue. Here is a sample processor:
SedaEndpoint queueEp = (SedaEndpoint)
exchange.getContext().getEndpoint("seda:test");
ConsumerTemplate cTemplate = (ConsumerTemplate)
exchange.getContext().getRegistry().lookupByName("cTemplate");
System.out.println("seda queue size before receive: " +
queueEp.getExchanges().size());
String msgBody = cTemplate.receiveBody(queueEp, 10, String.class);
System.out.println("seda queue size after receive: " +
queueEp.getExchanges().size());
The output is the following:
seda queue size before receive: 5
seda queue size after receive: 0
Should the receiveBody receive one message each time? The above processor
is running under a single Camel Timer thread. Here are the routes (the
above code is in testProc):
http://camel.apache.org/schema/spring";>
Have I missed anything? Thanks for any help!
--
View this message in context:
http://camel.465427.n5.nabble.com/Why-does-ConsumerTemplate-receiveBody-receive-more-than-one-message-at-a-time-from-SEDA-queue-tp5745568.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Asynchronous processing of routes
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
> *
>
>
> On Sun, Jan 5, 2014 at 2:27 AM, Claus Ibsen
> >
> 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 >
> 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: cib...@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
> >
>
--
Claus Ibsen
-
Red Hat, Inc.
Email: cib...@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
Re: Asynchronous processing of routes
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
*
On Sun, Jan 5, 2014 at 2:27 AM, Claus Ibsen 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 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: cib...@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
>
Re: Camel Message Attachment order
Hi Yeah well spotted, a good idea to use a linked so the order is preserved. Not sure if the attachments api has any hint to indicate ordering. Maybe some unique id of the attachment, many be used as workaround in current Camel version. Though fell free to log a JIRA, and as we love contributions you are welcome to work on a patch also. http://camel.apache.org/contributing.html On Sun, Jan 5, 2014 at 1:04 PM, rdehuyss wrote: > Hi all, > > for a project I'm working on where mail attachments are retrieved from a > gmail account, the order of the attachments is very important. > > In Camel, I use a SplitAttachmentsExpression to split all the attachments > and process them sequentially. > > However, I saw that the method createAttachments in DefaultMessage is using > a plain old HashMap, thus resulting in a random order of the attachments. If > this would be a LinkedHashMap, the order of the messages would be assured > when processing in Camel. > > Am I the first one bumping into this? Should I create a Jira ticket? > > Thx a lot, > Ronald > > > > -- > View this message in context: > http://camel.465427.n5.nabble.com/Camel-Message-Attachment-order-tp5745563.html > Sent from the Camel - Users mailing list archive at Nabble.com. -- Claus Ibsen - Red Hat, Inc. Email: cib...@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
Camel Message Attachment order
Hi all, for a project I'm working on where mail attachments are retrieved from a gmail account, the order of the attachments is very important. In Camel, I use a SplitAttachmentsExpression to split all the attachments and process them sequentially. However, I saw that the method createAttachments in DefaultMessage is using a plain old HashMap, thus resulting in a random order of the attachments. If this would be a LinkedHashMap, the order of the messages would be assured when processing in Camel. Am I the first one bumping into this? Should I create a Jira ticket? Thx a lot, Ronald -- View this message in context: http://camel.465427.n5.nabble.com/Camel-Message-Attachment-order-tp5745563.html Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Asynchronous processing of routes
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 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: cib...@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
