You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@camel.apache.org by sim085 <si...@hotmail.com> on 2016/09/23 12:49:20 UTC
Can't understand what inOnly is doing
I must not be understanding the concept which is why I decided to ask the
question before continue with my reading.
The book I am reading says "When the pattern is InOnly, the exchange
contains an IN message. For InOut, an OUT message also exists". I understood
this as meaning that in an InOnly message exchange pattern (MEP) there is no
OUT message.
Based on the above I expected the below to log "AAA" in the console. However
I am getting "BBB".
[code]
from("jetty:http://localhost:8282/")
.removeHeaders("*")
.transform(constant("AAA"))
.inOnly("direct:BBB")
.log("${body}");
from("direct:BBB")
.delay(5000)
.transform(constant("BBB"));
[/code]
If in an InOnly MEP the exchange has no OUT message shouldn't after the call
to "direct:BBB" the IN message have been used as OUT message and therefore
log the body value "AAA"?
What does inOnly mean then in the above code?
--
View this message in context: http://camel.465427.n5.nabble.com/Can-t-understand-what-inOnly-is-doing-tp5787961.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Can't understand what inOnly is doing
Posted by sim085 <si...@hotmail.com>.
Thanks Matt, so inOnly("direct:XXX") will not be asynchronous.
However what about the other side of the question (which is what I am mostly
intrested in)? Why isn't the OUT message lost at the end of the
[.inOnly("direct:BBB")] call?
I think I can summarise my question as follows :
How is [.inOnly("direct:BBB")] different than [.to("direct:BBB")] in the
examples I have provided? The results I get are the same regardless if I use
[.inOnly(...)] or [.to(...)].
Matt Sicker wrote
> The InOnly pattern is more of a one-way communication than it is
> asynchronous.
--
View this message in context: http://camel.465427.n5.nabble.com/Can-t-understand-what-inOnly-is-doing-tp5787961p5788036.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Can't understand what inOnly is doing
Posted by Brad Johnson <br...@mediadriver.com>.
The ExchangePattern appears to have more scope than I'd initially
believed. Just haven't had much need to delve into it that deep as most of
my use cases are for request/response we services or file unmarshaling or
even request/response with a pass of to seda or JMS and a quick response
back to the sender/requester. But if you look at the unit test I posted
earlier. It hast the following routes.
from("direct:in").to("seda:bbb").log("${exchangeId}").log("End Direct:
${body}");
from("seda:bbb").setBody(simple("bbb")).log("${exchangeId}").log("End SEDA:
${body}");
The following two test methods then invoke the direct:in with either a
sendBody (fire and forget) or requestBody (request/response). If you look
at the execution and results you'll notice that the entire global execution
order of the routes is change. With the fire and forget initial invocation
they are executed in a decoupled fashion. So the "End Direct:" shows "aaa"
while the End SEDA executes later and shows "bbb". When the request/reply
is used the whole is executed in a holistic pattern. So you end up with
"End Direct: bbb" and SEDA executes "inside" the calling route. It is
almost like you cut and past the entire SEDA route into the middle of the
direct route. It acts much more like a normal execution of a Java program
where method a calls method b calls method c. You expect the thread to run
all the way to end of method c and then return back through the call stack.
That's because the ProducerTemplate is setting the Exchange patter based
on the method you call and as you can see the effects are profound. You
can cut and past the unit test from my post above and run it and see that
difference. I also logged the exchange Ids to see what was happening when
it went from route to route. Each gets a new ID but that hasn't really
answered my question about whether it is a deep or shallow clone. Based on
behavior alone I'd say it is a shallow clone but it could also be that in
the context of a request/reply the end of the SEDA route contains an Out in
the exchange that by contract is then switched to the IN of the calling
route. But I'll have to run tests later to determine which. Ironic that
as much as I've used Camel I've never stumbled across this as fundamental
design or implementation problem. Although it is certainly possible it
would be useful in certain cases.
Claus has a bit a discussion on the point here:
http://stackoverflow.com/questions/15683944/do-we-need-inonly-annotation-or-setexchangepattern-pattern-inonly-if-we-ar
@Produce(uri = "direct:in") protected ProducerTemplate producer; @Test
public void fireAndForget() { producer.sendBody("aaa"); } @Test public void
requestReply() { String result = (String) producer.requestBody("aaa");
System.out.println("Result: "+ result); }
On Mon, Sep 26, 2016 at 8:22 AM, sim085 <si...@hotmail.com> wrote:
> I have checked the code of PatternDefinition.inOnly(...) and this just
> calls
> the PatternDefinition.to(...) method with the ExchangePattern set to
> InOnly.
>
> So let us forget the method inOnly(). What does it mean to set the
> ExchangePattern to "InOnly" (or even "InOut")?
>
> There are various ways how this can be done; .setExchangePattern(),
> .to(ExchangePattern e), .inOnly(...), inOut(...), etc.
>
> Is the ExchangePattern parameter just a flag which the called endpoint can
> ignore?
>
> For example the following code
>
> [code]
> from("jetty:http://localhost:8282/")
> .inOnly("direct:BBB")
> .process(new Processor(){
> public void process(Exchange e){
> System.out.println("AAA: Exchange
> Pattern is: " + e.getPattern());
> }
> });
>
> from("direct:BBB")
> .process(new Processor(){
> public void process(Exchange e){
> System.out.println("BBB: Exchange Pattern
> is: " + e.getPattern());
> }
> });
> [/code]
>
> As expected prints:
>
> > BBB: Exchange Pattern is: InOnly
> > AAA: Exchange Pattern is: InOut
>
> So is the ExchangePattern just a FLAG which the called endpoints can wrap
> logic around or ignore?
>
>
>
> Ranx wrote
> > I'm not even sure what an InOnly to a direct endpoint means quite frankly
>
>
>
>
>
> --
> View this message in context: http://camel.465427.n5.nabble.
> com/Can-t-understand-what-inOnly-is-doing-tp5787961p5788063.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
>
Re: Can't understand what inOnly is doing
Posted by sim085 <si...@hotmail.com>.
I have checked the code of PatternDefinition.inOnly(...) and this just calls
the PatternDefinition.to(...) method with the ExchangePattern set to InOnly.
So let us forget the method inOnly(). What does it mean to set the
ExchangePattern to "InOnly" (or even "InOut")?
There are various ways how this can be done; .setExchangePattern(),
.to(ExchangePattern e), .inOnly(...), inOut(...), etc.
Is the ExchangePattern parameter just a flag which the called endpoint can
ignore?
For example the following code
[code]
from("jetty:http://localhost:8282/")
.inOnly("direct:BBB")
.process(new Processor(){
public void process(Exchange e){
System.out.println("AAA: Exchange Pattern is: " + e.getPattern());
}
});
from("direct:BBB")
.process(new Processor(){
public void process(Exchange e){
System.out.println("BBB: Exchange Pattern is: " + e.getPattern());
}
});
[/code]
As expected prints:
> BBB: Exchange Pattern is: InOnly
> AAA: Exchange Pattern is: InOut
So is the ExchangePattern just a FLAG which the called endpoints can wrap
logic around or ignore?
Ranx wrote
> I'm not even sure what an InOnly to a direct endpoint means quite frankly
--
View this message in context: http://camel.465427.n5.nabble.com/Can-t-understand-what-inOnly-is-doing-tp5787961p5788063.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Can't understand what inOnly is doing
Posted by Brad Johnson <br...@mediadriver.com>.
@Sashika
I was just looking at that again right before I read your email. I created
and added a quick unit test to the thread. Basically the producer template
does inOnly when you do a sendBody and InOut when requestBody is used. If
it weren't already getting late I'd probably log the Exchange In/Out bodies
and see how they change.
Which makes sense because I know from the documents that you can modify the
behavior of certain endpoints that call the seda route to determine whether
it is request/reply or fire/forget. If memory serves in the docs there's a
bit showing how to modify a mina endpoint in to get the results of the SEDA
queue back.
On Sun, Sep 25, 2016 at 11:04 PM, Sashika <sa...@gmail.com> wrote:
> I've noticed the fire and forget only works with seda end point called with
> inOnly.
>
> On Sep 26, 2016 02:31, "Brad Johnson" <br...@mediadriver.com>
> wrote:
>
> > @Sim
> >
> > By the way, even if you set that to seda queue it's possible you'd get
> > different responses depending on thread execution order. As far as I
> know
> > Camel is doing a shallow clone there so if you changed the body in the
> seda
> > route it might still show up, on occasion, as showing exactly the same
> > message you are getting now and in others it would show what your log
> > statement shows it is expecting.
> >
> > In all likelihood I'd guess that you'd mostly see what you expect because
> > the calling thread would continue to execute but don't know that for
> sure.
> > This isn't they way I usually write routes so I'd actually have to sit
> down
> > and code it out and run it 100 times.
> >
> >
> >
> >
> > On Sun, Sep 25, 2016 at 2:38 PM, Brad Johnson <
> > brad.johnson@mediadriver.com>
> > wrote:
> >
> > > The direct is going to return a message regardless of what the upstream
> > > components say because at that point you are indicating that you *do
> > *want
> > > that route to return something to you. Much like a method with a void
> > > return calling a second method that returns a String. Just because
> the
> > > calling method isn't returning anything it doesn't indicate that the
> > second
> > > method in the sequence won't return something. Since direct is going to
> > do
> > > the request/reply before the rest of your first route finishes why
> would
> > > you expect it to operate differently? InOnly there does not take
> > priority
> > > over the call to direct. In the case you show why wouldn't you just
> say
> > > to(direct:BBB) instead. It is amounting to the same thing because
> > because
> > > direct: is a request/response and that call is going to happen
> regardless
> > > of what the calling route indicates.
> > >
> > > I'm not even sure what an InOnly to a direct endpoint means quite
> frankly
> > > as you are telling Camel two different things. The InOnly indicates a
> > fire
> > > and forget and the direct indicates a request/response. Switch that
> > around,
> > > what would an .InOut("seda:BBB") indicate? It's possible that Camel
> > would
> > > return something to you InOut but that's a bit of a head scratcher
> since
> > > your making a request/response call to a fire and forget endpoint.
> > >
> > > I guess I should have phrased it differently as Matt did and as the
> Camel
> > > documents in the links indicate. But if you are doing InOnly then I've
> > > found little point in using a direct or any synchronous component.
> > Perhaps
> > > there is one I just don't think about it that way. In fact, I don't
> > recall
> > > ever using InOnly or InOut explicitly since most endpoints are one or
> the
> > > other. So endpoints that are InOnly like SEDA are by their nature
> > running
> > > asynchronously from the calling route.
> > >
> > > What I have done many times is something like receiving a list of
> records
> > > or POJOs on an incoming synchronous web service call, spin through the
> > > elements validating them, and then drop them onto an asynchronous
> > > processing endpoint like the SEDA queue, and when done spinning through
> > the
> > > records return an OK or some other acknowledgement message. But I'm not
> > > waiting for or expecting anything back from the SEDA queue.
> > >
> > > But I really can't think of a need or reason why I'd set InOnly/InOut
> > > explicitly.
> > >
> > > The best definition I guess is as the camel docs in the link I sent
> > > calling them request/reply and event message.
> > >
> > > On Sun, Sep 25, 2016 at 10:25 AM, Matt Sicker <bo...@gmail.com>
> wrote:
> > >
> > >> The direct component is synchronous (it's implemented by simply
> > executing
> > >> the next Processor in the route). If you want to do it asynchronously,
> > you
> > >> can use the seda component which uses a BlockingQueue and a thread
> pool
> > or
> > >> one of the non-core components like disruptor, activemq, amqp, etc.
> > >>
> > >> The InOnly pattern is more of a one-way communication than it is
> > >> asynchronous.
> > >>
> > >> On 24 September 2016 at 13:26, sim085 <si...@hotmail.com> wrote:
> > >>
> > >> > If InOnly works asynchronous then why does it wait for "direct:BBB"
> to
> > >> > finish
> > >> > before the next step is executed?
> > >> > For example take the following code:
> > >> >
> > >> > [code]
> > >> > from("jetty:http://localhost:8282/")
> > >> > .log("Hello From A")
> > >> > .inOnly("direct:BBB") // asynchronous?
> > >> > .log("Goodbye From A");
> > >> >
> > >> > from("direct:BBB")
> > >> > .log("Hello From B")
> > >> > .delay(5000)
> > >> > .log("Goodbye From B");
> > >> > [/code]
> > >> >
> > >> > If the [.inOnly("direct:BBB")] was asynchronous then the console
> > should
> > >> > print "GoodBye From A" before "Goodbye from B" because of the
> > >> > [.delay(5000)]
> > >> > in route "direct:BBB". However what happens is that the console
> prints
> > >> > "Hello From A", "Hello From B", (waits 5 seconds), "Good Bye From
> B",
> > >> > "Goodbye From A". (screenshot1 attached).
> > >> >
> > >> > However beside this there is the fact that the message is not being
> > >> thrown
> > >> > away even though I am using the "inOnly" exchange patter. Take the
> > >> > following:
> > >> >
> > >> > [code]
> > >> > from("jetty:http://localhost:8282/")
> > >> > .transform(constant("AAA")) // Change body of
> OUT
> > >> > Message.
> > >> > .inOnly("direct:BBB") // Calling route
> > >> > direct:BBB using inOnly MEP.
> > >> > .log("I was waiting 'AAA' and got '${in.body}'");
> > >> >
> > >> > from("direct:BBB")
> > >> > .transform(constant("BBB")); // Change body of
> OUT
> > >> > Message.
> > >> > // But this should be "thrown away" as MEP
> is
> > >> > inOnly.
> > >> > [/code]
> > >> >
> > >> > The above code prints in the logs "I was waiting 'AAA' and got
> 'BBB'"
> > >> > (screenshot2 attached). However based on "If it is an InOnly then if
> > >> > there's
> > >> > a message at the end it is thrown away." shouldn't I have got "I was
> > >> > waiting
> > >> > 'AAA' and got 'AAA'"? Shouldn't the message at the end of route
> > >> > "direct:BBB"
> > >> > have been thrown away?
> > >> >
> > >> > Screenshot1:
> > >> > <http://camel.465427.n5.nabble.com/file/n5787994/screenshot1.png>
> > >> >
> > >> > Screenshot2:
> > >> > <http://camel.465427.n5.nabble.com/file/n5787994/screenshot2.png>
> > >> >
> > >> >
> > >> > Ranx wrote
> > >> > > InOnly is a fire-and-forget, asynchronous style of messaging.
> InOut
> > >> is a
> > >> > > synchronous or pseudo-synchronous* request-reply messaging as Matt
> > >> points
> > >> > > out.
> > >> > >
> > >> > > Part of the confusion is about the pattern set on the exchange to
> > >> > indicate
> > >> > > whether the data flow is InOut or InOnly. The other In/Out on the
> > >> > > Exchange
> > >> > > is about the data coming in and going out and is pretty much
> > >> invariant in
> > >> > > its existence and data structure. Unfortunately even that's a bit
> > >> > > misleading terminology as the data is always on the in except when
> > an
> > >> In
> > >> > > data on the Exchange follows the route all the way "In" to the
> last
> > >> > > endpoint and then if it is an InOut route the Out is what is
> > >> returned. If
> > >> > > it is an InOnly then if there's a message at the end it is thrown
> > >> away.
> > >> > >
> > >> > > InOut/InOnly are message flow patterns to set on the exchange.
> > In/Out
> > >> are
> > >> > > the data elements associated with the exchange at any given moment
> > in
> > >> the
> > >> > > route.
> > >> > >
> > >> > > *When I say pseudo-synchronous it is because Jetty continuations
> do
> > >> not
> > >> > > hold the calling thread but make callbacks. JMS
> InOut/request-reply
> > >> > > actually set up two queues under the covers, one to send the
> request
> > >> and
> > >> > > one to send the reply. I'd have to check again on whether the
> > calling
> > >> > > thread waits or if a callback mechanism is deployed. Obviously
> the
> > >> > latter
> > >> > > is preferable in terms of threading and performance.
> > >> > >
> > >> > > http://camel.apache.org/request-reply.html
> > >> > > http://camel.apache.org/event-message.html
> > >> > >
> > >> > > Brad
> > >> >
> > >> >
> > >> >
> > >> >
> > >> >
> > >> > --
> > >> > View this message in context: http://camel.465427.n5.nabble.
> > >> > com/Can-t-understand-what-inOnly-is-doing-tp5787961p5787994.html
> > >> > Sent from the Camel - Users mailing list archive at Nabble.com.
> > >> >
> > >>
> > >>
> > >>
> > >> --
> > >> Matt Sicker <bo...@gmail.com>
> > >>
> > >
> > >
> >
>
Re: Can't understand what inOnly is doing
Posted by Sashika <sa...@gmail.com>.
I've noticed the fire and forget only works with seda end point called with
inOnly.
On Sep 26, 2016 02:31, "Brad Johnson" <br...@mediadriver.com> wrote:
> @Sim
>
> By the way, even if you set that to seda queue it's possible you'd get
> different responses depending on thread execution order. As far as I know
> Camel is doing a shallow clone there so if you changed the body in the seda
> route it might still show up, on occasion, as showing exactly the same
> message you are getting now and in others it would show what your log
> statement shows it is expecting.
>
> In all likelihood I'd guess that you'd mostly see what you expect because
> the calling thread would continue to execute but don't know that for sure.
> This isn't they way I usually write routes so I'd actually have to sit down
> and code it out and run it 100 times.
>
>
>
>
> On Sun, Sep 25, 2016 at 2:38 PM, Brad Johnson <
> brad.johnson@mediadriver.com>
> wrote:
>
> > The direct is going to return a message regardless of what the upstream
> > components say because at that point you are indicating that you *do
> *want
> > that route to return something to you. Much like a method with a void
> > return calling a second method that returns a String. Just because the
> > calling method isn't returning anything it doesn't indicate that the
> second
> > method in the sequence won't return something. Since direct is going to
> do
> > the request/reply before the rest of your first route finishes why would
> > you expect it to operate differently? InOnly there does not take
> priority
> > over the call to direct. In the case you show why wouldn't you just say
> > to(direct:BBB) instead. It is amounting to the same thing because
> because
> > direct: is a request/response and that call is going to happen regardless
> > of what the calling route indicates.
> >
> > I'm not even sure what an InOnly to a direct endpoint means quite frankly
> > as you are telling Camel two different things. The InOnly indicates a
> fire
> > and forget and the direct indicates a request/response. Switch that
> around,
> > what would an .InOut("seda:BBB") indicate? It's possible that Camel
> would
> > return something to you InOut but that's a bit of a head scratcher since
> > your making a request/response call to a fire and forget endpoint.
> >
> > I guess I should have phrased it differently as Matt did and as the Camel
> > documents in the links indicate. But if you are doing InOnly then I've
> > found little point in using a direct or any synchronous component.
> Perhaps
> > there is one I just don't think about it that way. In fact, I don't
> recall
> > ever using InOnly or InOut explicitly since most endpoints are one or the
> > other. So endpoints that are InOnly like SEDA are by their nature
> running
> > asynchronously from the calling route.
> >
> > What I have done many times is something like receiving a list of records
> > or POJOs on an incoming synchronous web service call, spin through the
> > elements validating them, and then drop them onto an asynchronous
> > processing endpoint like the SEDA queue, and when done spinning through
> the
> > records return an OK or some other acknowledgement message. But I'm not
> > waiting for or expecting anything back from the SEDA queue.
> >
> > But I really can't think of a need or reason why I'd set InOnly/InOut
> > explicitly.
> >
> > The best definition I guess is as the camel docs in the link I sent
> > calling them request/reply and event message.
> >
> > On Sun, Sep 25, 2016 at 10:25 AM, Matt Sicker <bo...@gmail.com> wrote:
> >
> >> The direct component is synchronous (it's implemented by simply
> executing
> >> the next Processor in the route). If you want to do it asynchronously,
> you
> >> can use the seda component which uses a BlockingQueue and a thread pool
> or
> >> one of the non-core components like disruptor, activemq, amqp, etc.
> >>
> >> The InOnly pattern is more of a one-way communication than it is
> >> asynchronous.
> >>
> >> On 24 September 2016 at 13:26, sim085 <si...@hotmail.com> wrote:
> >>
> >> > If InOnly works asynchronous then why does it wait for "direct:BBB" to
> >> > finish
> >> > before the next step is executed?
> >> > For example take the following code:
> >> >
> >> > [code]
> >> > from("jetty:http://localhost:8282/")
> >> > .log("Hello From A")
> >> > .inOnly("direct:BBB") // asynchronous?
> >> > .log("Goodbye From A");
> >> >
> >> > from("direct:BBB")
> >> > .log("Hello From B")
> >> > .delay(5000)
> >> > .log("Goodbye From B");
> >> > [/code]
> >> >
> >> > If the [.inOnly("direct:BBB")] was asynchronous then the console
> should
> >> > print "GoodBye From A" before "Goodbye from B" because of the
> >> > [.delay(5000)]
> >> > in route "direct:BBB". However what happens is that the console prints
> >> > "Hello From A", "Hello From B", (waits 5 seconds), "Good Bye From B",
> >> > "Goodbye From A". (screenshot1 attached).
> >> >
> >> > However beside this there is the fact that the message is not being
> >> thrown
> >> > away even though I am using the "inOnly" exchange patter. Take the
> >> > following:
> >> >
> >> > [code]
> >> > from("jetty:http://localhost:8282/")
> >> > .transform(constant("AAA")) // Change body of OUT
> >> > Message.
> >> > .inOnly("direct:BBB") // Calling route
> >> > direct:BBB using inOnly MEP.
> >> > .log("I was waiting 'AAA' and got '${in.body}'");
> >> >
> >> > from("direct:BBB")
> >> > .transform(constant("BBB")); // Change body of OUT
> >> > Message.
> >> > // But this should be "thrown away" as MEP is
> >> > inOnly.
> >> > [/code]
> >> >
> >> > The above code prints in the logs "I was waiting 'AAA' and got 'BBB'"
> >> > (screenshot2 attached). However based on "If it is an InOnly then if
> >> > there's
> >> > a message at the end it is thrown away." shouldn't I have got "I was
> >> > waiting
> >> > 'AAA' and got 'AAA'"? Shouldn't the message at the end of route
> >> > "direct:BBB"
> >> > have been thrown away?
> >> >
> >> > Screenshot1:
> >> > <http://camel.465427.n5.nabble.com/file/n5787994/screenshot1.png>
> >> >
> >> > Screenshot2:
> >> > <http://camel.465427.n5.nabble.com/file/n5787994/screenshot2.png>
> >> >
> >> >
> >> > Ranx wrote
> >> > > InOnly is a fire-and-forget, asynchronous style of messaging. InOut
> >> is a
> >> > > synchronous or pseudo-synchronous* request-reply messaging as Matt
> >> points
> >> > > out.
> >> > >
> >> > > Part of the confusion is about the pattern set on the exchange to
> >> > indicate
> >> > > whether the data flow is InOut or InOnly. The other In/Out on the
> >> > > Exchange
> >> > > is about the data coming in and going out and is pretty much
> >> invariant in
> >> > > its existence and data structure. Unfortunately even that's a bit
> >> > > misleading terminology as the data is always on the in except when
> an
> >> In
> >> > > data on the Exchange follows the route all the way "In" to the last
> >> > > endpoint and then if it is an InOut route the Out is what is
> >> returned. If
> >> > > it is an InOnly then if there's a message at the end it is thrown
> >> away.
> >> > >
> >> > > InOut/InOnly are message flow patterns to set on the exchange.
> In/Out
> >> are
> >> > > the data elements associated with the exchange at any given moment
> in
> >> the
> >> > > route.
> >> > >
> >> > > *When I say pseudo-synchronous it is because Jetty continuations do
> >> not
> >> > > hold the calling thread but make callbacks. JMS InOut/request-reply
> >> > > actually set up two queues under the covers, one to send the request
> >> and
> >> > > one to send the reply. I'd have to check again on whether the
> calling
> >> > > thread waits or if a callback mechanism is deployed. Obviously the
> >> > latter
> >> > > is preferable in terms of threading and performance.
> >> > >
> >> > > http://camel.apache.org/request-reply.html
> >> > > http://camel.apache.org/event-message.html
> >> > >
> >> > > Brad
> >> >
> >> >
> >> >
> >> >
> >> >
> >> > --
> >> > View this message in context: http://camel.465427.n5.nabble.
> >> > com/Can-t-understand-what-inOnly-is-doing-tp5787961p5787994.html
> >> > Sent from the Camel - Users mailing list archive at Nabble.com.
> >> >
> >>
> >>
> >>
> >> --
> >> Matt Sicker <bo...@gmail.com>
> >>
> >
> >
>
Re: Can't understand what inOnly is doing
Posted by Brad Johnson <br...@mediadriver.com>.
By the way I did a quick test out of curiosity and you might find the
results interesting. It uses the exact same routes and producer template
to fire messages. One is sent in fire and forget "sendBody" and the other
is sent request reply with "requestBody".
The fire and forget at the end of the first route will print out the same
value that is sent in. If you invoke it as a request/response it prints
out the results of the transform that occurs from the call to the seda
route. If you invoke it as an event then you'll see the end of the direct
invocation printing out what was sent in. I've put in exchange ID logging
as well so you can see where it changes across routes.
So invoking with requestBody you get the following execution order:
[amel-1) thread #0 - seda://bbb] route2 INFO
ID-63103-1474866480454-0-4
[amel-1) thread #0 - seda://bbb] route2 INFO End
SEDA: bbb
[ main] route1 INFO
ID-63103-1474866480454-0-2
[ main] route1 INFO End
Direct: bbb
Result: bbb
If you invoke with the fire and forget sendBody you'll see:
[ main] route3 INFO
ID--63103-1474866480454-1-2
[ main] route3 INFO End
Direct: aaa
[ main] AsynchTest INFO
********************************************************************************
[ main] AsynchTest INFO
Testing done: fireAndForget(org.enjekt.panda.server.AsynchTest)
[ main] AsynchTest INFO Took:
0.000 seconds (0 millis)
[ main] AsynchTest INFO
********************************************************************************
[ main] DefaultCamelContext INFO
Apache Camel 2.17.3 (CamelContext: camel-2) is shutting down
[ main] DefaultShutdownStrategy INFO
Starting to graceful shutdown 2 routes (timeout 10 seconds)
[el-2) thread #3 - ShutdownTask] DefaultShutdownStrategy INFO
Waiting as there are still 1 inflight and pending exchanges to complete,
timeout in 10 seconds. Inflights per route: [route4 = 1]
[amel-2) thread #2 - seda://bbb] route4 INFO
ID-63103-1474866480454-1-4
[amel-2) thread #2 - seda://bbb] route4 INFO End
SEDA: bbb
So in the request/reply it logs the result of the entire set of routes and
prints out that return as well. The event style logs what you sent in and
you can see the execution is not ordered the same.
public class AsynchTest extends CamelTestSupport { protected RoutesBuilder
createRouteBuilder() throws Exception { return new RouteBuilder() {
@Override public void configure() {
from("direct:in").to("seda:bbb").log("${exchangeId}").log("End Direct:
${body}");
from("seda:bbb").setBody(simple("bbb")).log("${exchangeId}").log("End SEDA:
${body}"); } }; } @Produce(uri = "direct:in") protected ProducerTemplate
producer; @Test public void fireAndForget() { producer.sendBody("aaa"); }
@Test public void requestReply() { String result = (String)
producer.requestBody("aaa"); System.out.println("Result: "+ result); } }
On Sun, Sep 25, 2016 at 4:01 PM, Brad Johnson <br...@mediadriver.com>
wrote:
> @Sim
>
> By the way, even if you set that to seda queue it's possible you'd get
> different responses depending on thread execution order. As far as I know
> Camel is doing a shallow clone there so if you changed the body in the seda
> route it might still show up, on occasion, as showing exactly the same
> message you are getting now and in others it would show what your log
> statement shows it is expecting.
>
> In all likelihood I'd guess that you'd mostly see what you expect because
> the calling thread would continue to execute but don't know that for sure.
> This isn't they way I usually write routes so I'd actually have to sit down
> and code it out and run it 100 times.
>
>
>
>
> On Sun, Sep 25, 2016 at 2:38 PM, Brad Johnson <
> brad.johnson@mediadriver.com> wrote:
>
>> The direct is going to return a message regardless of what the upstream
>> components say because at that point you are indicating that you *do *want
>> that route to return something to you. Much like a method with a void
>> return calling a second method that returns a String. Just because the
>> calling method isn't returning anything it doesn't indicate that the second
>> method in the sequence won't return something. Since direct is going to do
>> the request/reply before the rest of your first route finishes why would
>> you expect it to operate differently? InOnly there does not take priority
>> over the call to direct. In the case you show why wouldn't you just say
>> to(direct:BBB) instead. It is amounting to the same thing because because
>> direct: is a request/response and that call is going to happen regardless
>> of what the calling route indicates.
>>
>> I'm not even sure what an InOnly to a direct endpoint means quite frankly
>> as you are telling Camel two different things. The InOnly indicates a fire
>> and forget and the direct indicates a request/response. Switch that around,
>> what would an .InOut("seda:BBB") indicate? It's possible that Camel would
>> return something to you InOut but that's a bit of a head scratcher since
>> your making a request/response call to a fire and forget endpoint.
>>
>> I guess I should have phrased it differently as Matt did and as the Camel
>> documents in the links indicate. But if you are doing InOnly then I've
>> found little point in using a direct or any synchronous component. Perhaps
>> there is one I just don't think about it that way. In fact, I don't recall
>> ever using InOnly or InOut explicitly since most endpoints are one or the
>> other. So endpoints that are InOnly like SEDA are by their nature running
>> asynchronously from the calling route.
>>
>> What I have done many times is something like receiving a list of records
>> or POJOs on an incoming synchronous web service call, spin through the
>> elements validating them, and then drop them onto an asynchronous
>> processing endpoint like the SEDA queue, and when done spinning through the
>> records return an OK or some other acknowledgement message. But I'm not
>> waiting for or expecting anything back from the SEDA queue.
>>
>> But I really can't think of a need or reason why I'd set InOnly/InOut
>> explicitly.
>>
>> The best definition I guess is as the camel docs in the link I sent
>> calling them request/reply and event message.
>>
>> On Sun, Sep 25, 2016 at 10:25 AM, Matt Sicker <bo...@gmail.com> wrote:
>>
>>> The direct component is synchronous (it's implemented by simply executing
>>> the next Processor in the route). If you want to do it asynchronously,
>>> you
>>> can use the seda component which uses a BlockingQueue and a thread pool
>>> or
>>> one of the non-core components like disruptor, activemq, amqp, etc.
>>>
>>> The InOnly pattern is more of a one-way communication than it is
>>> asynchronous.
>>>
>>> On 24 September 2016 at 13:26, sim085 <si...@hotmail.com> wrote:
>>>
>>> > If InOnly works asynchronous then why does it wait for "direct:BBB" to
>>> > finish
>>> > before the next step is executed?
>>> > For example take the following code:
>>> >
>>> > [code]
>>> > from("jetty:http://localhost:8282/")
>>> > .log("Hello From A")
>>> > .inOnly("direct:BBB") // asynchronous?
>>> > .log("Goodbye From A");
>>> >
>>> > from("direct:BBB")
>>> > .log("Hello From B")
>>> > .delay(5000)
>>> > .log("Goodbye From B");
>>> > [/code]
>>> >
>>> > If the [.inOnly("direct:BBB")] was asynchronous then the console should
>>> > print "GoodBye From A" before "Goodbye from B" because of the
>>> > [.delay(5000)]
>>> > in route "direct:BBB". However what happens is that the console prints
>>> > "Hello From A", "Hello From B", (waits 5 seconds), "Good Bye From B",
>>> > "Goodbye From A". (screenshot1 attached).
>>> >
>>> > However beside this there is the fact that the message is not being
>>> thrown
>>> > away even though I am using the "inOnly" exchange patter. Take the
>>> > following:
>>> >
>>> > [code]
>>> > from("jetty:http://localhost:8282/")
>>> > .transform(constant("AAA")) // Change body of OUT
>>> > Message.
>>> > .inOnly("direct:BBB") // Calling route
>>> > direct:BBB using inOnly MEP.
>>> > .log("I was waiting 'AAA' and got '${in.body}'");
>>> >
>>> > from("direct:BBB")
>>> > .transform(constant("BBB")); // Change body of OUT
>>> > Message.
>>> > // But this should be "thrown away" as MEP is
>>> > inOnly.
>>> > [/code]
>>> >
>>> > The above code prints in the logs "I was waiting 'AAA' and got 'BBB'"
>>> > (screenshot2 attached). However based on "If it is an InOnly then if
>>> > there's
>>> > a message at the end it is thrown away." shouldn't I have got "I was
>>> > waiting
>>> > 'AAA' and got 'AAA'"? Shouldn't the message at the end of route
>>> > "direct:BBB"
>>> > have been thrown away?
>>> >
>>> > Screenshot1:
>>> > <http://camel.465427.n5.nabble.com/file/n5787994/screenshot1.png>
>>> >
>>> > Screenshot2:
>>> > <http://camel.465427.n5.nabble.com/file/n5787994/screenshot2.png>
>>> >
>>> >
>>> > Ranx wrote
>>> > > InOnly is a fire-and-forget, asynchronous style of messaging. InOut
>>> is a
>>> > > synchronous or pseudo-synchronous* request-reply messaging as Matt
>>> points
>>> > > out.
>>> > >
>>> > > Part of the confusion is about the pattern set on the exchange to
>>> > indicate
>>> > > whether the data flow is InOut or InOnly. The other In/Out on the
>>> > > Exchange
>>> > > is about the data coming in and going out and is pretty much
>>> invariant in
>>> > > its existence and data structure. Unfortunately even that's a bit
>>> > > misleading terminology as the data is always on the in except when
>>> an In
>>> > > data on the Exchange follows the route all the way "In" to the last
>>> > > endpoint and then if it is an InOut route the Out is what is
>>> returned. If
>>> > > it is an InOnly then if there's a message at the end it is thrown
>>> away.
>>> > >
>>> > > InOut/InOnly are message flow patterns to set on the exchange.
>>> In/Out are
>>> > > the data elements associated with the exchange at any given moment
>>> in the
>>> > > route.
>>> > >
>>> > > *When I say pseudo-synchronous it is because Jetty continuations do
>>> not
>>> > > hold the calling thread but make callbacks. JMS InOut/request-reply
>>> > > actually set up two queues under the covers, one to send the request
>>> and
>>> > > one to send the reply. I'd have to check again on whether the calling
>>> > > thread waits or if a callback mechanism is deployed. Obviously the
>>> > latter
>>> > > is preferable in terms of threading and performance.
>>> > >
>>> > > http://camel.apache.org/request-reply.html
>>> > > http://camel.apache.org/event-message.html
>>> > >
>>> > > Brad
>>> >
>>> >
>>> >
>>> >
>>> >
>>> > --
>>> > View this message in context: http://camel.465427.n5.nabble.
>>> > com/Can-t-understand-what-inOnly-is-doing-tp5787961p5787994.html
>>> > Sent from the Camel - Users mailing list archive at Nabble.com.
>>> >
>>>
>>>
>>>
>>> --
>>> Matt Sicker <bo...@gmail.com>
>>>
>>
>>
>
Re: Can't understand what inOnly is doing
Posted by Brad Johnson <br...@mediadriver.com>.
@Sim
By the way, even if you set that to seda queue it's possible you'd get
different responses depending on thread execution order. As far as I know
Camel is doing a shallow clone there so if you changed the body in the seda
route it might still show up, on occasion, as showing exactly the same
message you are getting now and in others it would show what your log
statement shows it is expecting.
In all likelihood I'd guess that you'd mostly see what you expect because
the calling thread would continue to execute but don't know that for sure.
This isn't they way I usually write routes so I'd actually have to sit down
and code it out and run it 100 times.
On Sun, Sep 25, 2016 at 2:38 PM, Brad Johnson <br...@mediadriver.com>
wrote:
> The direct is going to return a message regardless of what the upstream
> components say because at that point you are indicating that you *do *want
> that route to return something to you. Much like a method with a void
> return calling a second method that returns a String. Just because the
> calling method isn't returning anything it doesn't indicate that the second
> method in the sequence won't return something. Since direct is going to do
> the request/reply before the rest of your first route finishes why would
> you expect it to operate differently? InOnly there does not take priority
> over the call to direct. In the case you show why wouldn't you just say
> to(direct:BBB) instead. It is amounting to the same thing because because
> direct: is a request/response and that call is going to happen regardless
> of what the calling route indicates.
>
> I'm not even sure what an InOnly to a direct endpoint means quite frankly
> as you are telling Camel two different things. The InOnly indicates a fire
> and forget and the direct indicates a request/response. Switch that around,
> what would an .InOut("seda:BBB") indicate? It's possible that Camel would
> return something to you InOut but that's a bit of a head scratcher since
> your making a request/response call to a fire and forget endpoint.
>
> I guess I should have phrased it differently as Matt did and as the Camel
> documents in the links indicate. But if you are doing InOnly then I've
> found little point in using a direct or any synchronous component. Perhaps
> there is one I just don't think about it that way. In fact, I don't recall
> ever using InOnly or InOut explicitly since most endpoints are one or the
> other. So endpoints that are InOnly like SEDA are by their nature running
> asynchronously from the calling route.
>
> What I have done many times is something like receiving a list of records
> or POJOs on an incoming synchronous web service call, spin through the
> elements validating them, and then drop them onto an asynchronous
> processing endpoint like the SEDA queue, and when done spinning through the
> records return an OK or some other acknowledgement message. But I'm not
> waiting for or expecting anything back from the SEDA queue.
>
> But I really can't think of a need or reason why I'd set InOnly/InOut
> explicitly.
>
> The best definition I guess is as the camel docs in the link I sent
> calling them request/reply and event message.
>
> On Sun, Sep 25, 2016 at 10:25 AM, Matt Sicker <bo...@gmail.com> wrote:
>
>> The direct component is synchronous (it's implemented by simply executing
>> the next Processor in the route). If you want to do it asynchronously, you
>> can use the seda component which uses a BlockingQueue and a thread pool or
>> one of the non-core components like disruptor, activemq, amqp, etc.
>>
>> The InOnly pattern is more of a one-way communication than it is
>> asynchronous.
>>
>> On 24 September 2016 at 13:26, sim085 <si...@hotmail.com> wrote:
>>
>> > If InOnly works asynchronous then why does it wait for "direct:BBB" to
>> > finish
>> > before the next step is executed?
>> > For example take the following code:
>> >
>> > [code]
>> > from("jetty:http://localhost:8282/")
>> > .log("Hello From A")
>> > .inOnly("direct:BBB") // asynchronous?
>> > .log("Goodbye From A");
>> >
>> > from("direct:BBB")
>> > .log("Hello From B")
>> > .delay(5000)
>> > .log("Goodbye From B");
>> > [/code]
>> >
>> > If the [.inOnly("direct:BBB")] was asynchronous then the console should
>> > print "GoodBye From A" before "Goodbye from B" because of the
>> > [.delay(5000)]
>> > in route "direct:BBB". However what happens is that the console prints
>> > "Hello From A", "Hello From B", (waits 5 seconds), "Good Bye From B",
>> > "Goodbye From A". (screenshot1 attached).
>> >
>> > However beside this there is the fact that the message is not being
>> thrown
>> > away even though I am using the "inOnly" exchange patter. Take the
>> > following:
>> >
>> > [code]
>> > from("jetty:http://localhost:8282/")
>> > .transform(constant("AAA")) // Change body of OUT
>> > Message.
>> > .inOnly("direct:BBB") // Calling route
>> > direct:BBB using inOnly MEP.
>> > .log("I was waiting 'AAA' and got '${in.body}'");
>> >
>> > from("direct:BBB")
>> > .transform(constant("BBB")); // Change body of OUT
>> > Message.
>> > // But this should be "thrown away" as MEP is
>> > inOnly.
>> > [/code]
>> >
>> > The above code prints in the logs "I was waiting 'AAA' and got 'BBB'"
>> > (screenshot2 attached). However based on "If it is an InOnly then if
>> > there's
>> > a message at the end it is thrown away." shouldn't I have got "I was
>> > waiting
>> > 'AAA' and got 'AAA'"? Shouldn't the message at the end of route
>> > "direct:BBB"
>> > have been thrown away?
>> >
>> > Screenshot1:
>> > <http://camel.465427.n5.nabble.com/file/n5787994/screenshot1.png>
>> >
>> > Screenshot2:
>> > <http://camel.465427.n5.nabble.com/file/n5787994/screenshot2.png>
>> >
>> >
>> > Ranx wrote
>> > > InOnly is a fire-and-forget, asynchronous style of messaging. InOut
>> is a
>> > > synchronous or pseudo-synchronous* request-reply messaging as Matt
>> points
>> > > out.
>> > >
>> > > Part of the confusion is about the pattern set on the exchange to
>> > indicate
>> > > whether the data flow is InOut or InOnly. The other In/Out on the
>> > > Exchange
>> > > is about the data coming in and going out and is pretty much
>> invariant in
>> > > its existence and data structure. Unfortunately even that's a bit
>> > > misleading terminology as the data is always on the in except when an
>> In
>> > > data on the Exchange follows the route all the way "In" to the last
>> > > endpoint and then if it is an InOut route the Out is what is
>> returned. If
>> > > it is an InOnly then if there's a message at the end it is thrown
>> away.
>> > >
>> > > InOut/InOnly are message flow patterns to set on the exchange. In/Out
>> are
>> > > the data elements associated with the exchange at any given moment in
>> the
>> > > route.
>> > >
>> > > *When I say pseudo-synchronous it is because Jetty continuations do
>> not
>> > > hold the calling thread but make callbacks. JMS InOut/request-reply
>> > > actually set up two queues under the covers, one to send the request
>> and
>> > > one to send the reply. I'd have to check again on whether the calling
>> > > thread waits or if a callback mechanism is deployed. Obviously the
>> > latter
>> > > is preferable in terms of threading and performance.
>> > >
>> > > http://camel.apache.org/request-reply.html
>> > > http://camel.apache.org/event-message.html
>> > >
>> > > Brad
>> >
>> >
>> >
>> >
>> >
>> > --
>> > View this message in context: http://camel.465427.n5.nabble.
>> > com/Can-t-understand-what-inOnly-is-doing-tp5787961p5787994.html
>> > Sent from the Camel - Users mailing list archive at Nabble.com.
>> >
>>
>>
>>
>> --
>> Matt Sicker <bo...@gmail.com>
>>
>
>
Re: Can't understand what inOnly is doing
Posted by Brad Johnson <br...@mediadriver.com>.
The direct is going to return a message regardless of what the upstream
components say because at that point you are indicating that you *do *want
that route to return something to you. Much like a method with a void
return calling a second method that returns a String. Just because the
calling method isn't returning anything it doesn't indicate that the second
method in the sequence won't return something. Since direct is going to do
the request/reply before the rest of your first route finishes why would
you expect it to operate differently? InOnly there does not take priority
over the call to direct. In the case you show why wouldn't you just say
to(direct:BBB) instead. It is amounting to the same thing because because
direct: is a request/response and that call is going to happen regardless
of what the calling route indicates.
I'm not even sure what an InOnly to a direct endpoint means quite frankly
as you are telling Camel two different things. The InOnly indicates a fire
and forget and the direct indicates a request/response. Switch that around,
what would an .InOut("seda:BBB") indicate? It's possible that Camel would
return something to you InOut but that's a bit of a head scratcher since
your making a request/response call to a fire and forget endpoint.
I guess I should have phrased it differently as Matt did and as the Camel
documents in the links indicate. But if you are doing InOnly then I've
found little point in using a direct or any synchronous component. Perhaps
there is one I just don't think about it that way. In fact, I don't recall
ever using InOnly or InOut explicitly since most endpoints are one or the
other. So endpoints that are InOnly like SEDA are by their nature running
asynchronously from the calling route.
What I have done many times is something like receiving a list of records
or POJOs on an incoming synchronous web service call, spin through the
elements validating them, and then drop them onto an asynchronous
processing endpoint like the SEDA queue, and when done spinning through the
records return an OK or some other acknowledgement message. But I'm not
waiting for or expecting anything back from the SEDA queue.
But I really can't think of a need or reason why I'd set InOnly/InOut
explicitly.
The best definition I guess is as the camel docs in the link I sent calling
them request/reply and event message.
On Sun, Sep 25, 2016 at 10:25 AM, Matt Sicker <bo...@gmail.com> wrote:
> The direct component is synchronous (it's implemented by simply executing
> the next Processor in the route). If you want to do it asynchronously, you
> can use the seda component which uses a BlockingQueue and a thread pool or
> one of the non-core components like disruptor, activemq, amqp, etc.
>
> The InOnly pattern is more of a one-way communication than it is
> asynchronous.
>
> On 24 September 2016 at 13:26, sim085 <si...@hotmail.com> wrote:
>
> > If InOnly works asynchronous then why does it wait for "direct:BBB" to
> > finish
> > before the next step is executed?
> > For example take the following code:
> >
> > [code]
> > from("jetty:http://localhost:8282/")
> > .log("Hello From A")
> > .inOnly("direct:BBB") // asynchronous?
> > .log("Goodbye From A");
> >
> > from("direct:BBB")
> > .log("Hello From B")
> > .delay(5000)
> > .log("Goodbye From B");
> > [/code]
> >
> > If the [.inOnly("direct:BBB")] was asynchronous then the console should
> > print "GoodBye From A" before "Goodbye from B" because of the
> > [.delay(5000)]
> > in route "direct:BBB". However what happens is that the console prints
> > "Hello From A", "Hello From B", (waits 5 seconds), "Good Bye From B",
> > "Goodbye From A". (screenshot1 attached).
> >
> > However beside this there is the fact that the message is not being
> thrown
> > away even though I am using the "inOnly" exchange patter. Take the
> > following:
> >
> > [code]
> > from("jetty:http://localhost:8282/")
> > .transform(constant("AAA")) // Change body of OUT
> > Message.
> > .inOnly("direct:BBB") // Calling route
> > direct:BBB using inOnly MEP.
> > .log("I was waiting 'AAA' and got '${in.body}'");
> >
> > from("direct:BBB")
> > .transform(constant("BBB")); // Change body of OUT
> > Message.
> > // But this should be "thrown away" as MEP is
> > inOnly.
> > [/code]
> >
> > The above code prints in the logs "I was waiting 'AAA' and got 'BBB'"
> > (screenshot2 attached). However based on "If it is an InOnly then if
> > there's
> > a message at the end it is thrown away." shouldn't I have got "I was
> > waiting
> > 'AAA' and got 'AAA'"? Shouldn't the message at the end of route
> > "direct:BBB"
> > have been thrown away?
> >
> > Screenshot1:
> > <http://camel.465427.n5.nabble.com/file/n5787994/screenshot1.png>
> >
> > Screenshot2:
> > <http://camel.465427.n5.nabble.com/file/n5787994/screenshot2.png>
> >
> >
> > Ranx wrote
> > > InOnly is a fire-and-forget, asynchronous style of messaging. InOut
> is a
> > > synchronous or pseudo-synchronous* request-reply messaging as Matt
> points
> > > out.
> > >
> > > Part of the confusion is about the pattern set on the exchange to
> > indicate
> > > whether the data flow is InOut or InOnly. The other In/Out on the
> > > Exchange
> > > is about the data coming in and going out and is pretty much invariant
> in
> > > its existence and data structure. Unfortunately even that's a bit
> > > misleading terminology as the data is always on the in except when an
> In
> > > data on the Exchange follows the route all the way "In" to the last
> > > endpoint and then if it is an InOut route the Out is what is returned.
> If
> > > it is an InOnly then if there's a message at the end it is thrown away.
> > >
> > > InOut/InOnly are message flow patterns to set on the exchange. In/Out
> are
> > > the data elements associated with the exchange at any given moment in
> the
> > > route.
> > >
> > > *When I say pseudo-synchronous it is because Jetty continuations do not
> > > hold the calling thread but make callbacks. JMS InOut/request-reply
> > > actually set up two queues under the covers, one to send the request
> and
> > > one to send the reply. I'd have to check again on whether the calling
> > > thread waits or if a callback mechanism is deployed. Obviously the
> > latter
> > > is preferable in terms of threading and performance.
> > >
> > > http://camel.apache.org/request-reply.html
> > > http://camel.apache.org/event-message.html
> > >
> > > Brad
> >
> >
> >
> >
> >
> > --
> > View this message in context: http://camel.465427.n5.nabble.
> > com/Can-t-understand-what-inOnly-is-doing-tp5787961p5787994.html
> > Sent from the Camel - Users mailing list archive at Nabble.com.
> >
>
>
>
> --
> Matt Sicker <bo...@gmail.com>
>
Re: Can't understand what inOnly is doing
Posted by Matt Sicker <bo...@gmail.com>.
The direct component is synchronous (it's implemented by simply executing
the next Processor in the route). If you want to do it asynchronously, you
can use the seda component which uses a BlockingQueue and a thread pool or
one of the non-core components like disruptor, activemq, amqp, etc.
The InOnly pattern is more of a one-way communication than it is
asynchronous.
On 24 September 2016 at 13:26, sim085 <si...@hotmail.com> wrote:
> If InOnly works asynchronous then why does it wait for "direct:BBB" to
> finish
> before the next step is executed?
> For example take the following code:
>
> [code]
> from("jetty:http://localhost:8282/")
> .log("Hello From A")
> .inOnly("direct:BBB") // asynchronous?
> .log("Goodbye From A");
>
> from("direct:BBB")
> .log("Hello From B")
> .delay(5000)
> .log("Goodbye From B");
> [/code]
>
> If the [.inOnly("direct:BBB")] was asynchronous then the console should
> print "GoodBye From A" before "Goodbye from B" because of the
> [.delay(5000)]
> in route "direct:BBB". However what happens is that the console prints
> "Hello From A", "Hello From B", (waits 5 seconds), "Good Bye From B",
> "Goodbye From A". (screenshot1 attached).
>
> However beside this there is the fact that the message is not being thrown
> away even though I am using the "inOnly" exchange patter. Take the
> following:
>
> [code]
> from("jetty:http://localhost:8282/")
> .transform(constant("AAA")) // Change body of OUT
> Message.
> .inOnly("direct:BBB") // Calling route
> direct:BBB using inOnly MEP.
> .log("I was waiting 'AAA' and got '${in.body}'");
>
> from("direct:BBB")
> .transform(constant("BBB")); // Change body of OUT
> Message.
> // But this should be "thrown away" as MEP is
> inOnly.
> [/code]
>
> The above code prints in the logs "I was waiting 'AAA' and got 'BBB'"
> (screenshot2 attached). However based on "If it is an InOnly then if
> there's
> a message at the end it is thrown away." shouldn't I have got "I was
> waiting
> 'AAA' and got 'AAA'"? Shouldn't the message at the end of route
> "direct:BBB"
> have been thrown away?
>
> Screenshot1:
> <http://camel.465427.n5.nabble.com/file/n5787994/screenshot1.png>
>
> Screenshot2:
> <http://camel.465427.n5.nabble.com/file/n5787994/screenshot2.png>
>
>
> Ranx wrote
> > InOnly is a fire-and-forget, asynchronous style of messaging. InOut is a
> > synchronous or pseudo-synchronous* request-reply messaging as Matt points
> > out.
> >
> > Part of the confusion is about the pattern set on the exchange to
> indicate
> > whether the data flow is InOut or InOnly. The other In/Out on the
> > Exchange
> > is about the data coming in and going out and is pretty much invariant in
> > its existence and data structure. Unfortunately even that's a bit
> > misleading terminology as the data is always on the in except when an In
> > data on the Exchange follows the route all the way "In" to the last
> > endpoint and then if it is an InOut route the Out is what is returned. If
> > it is an InOnly then if there's a message at the end it is thrown away.
> >
> > InOut/InOnly are message flow patterns to set on the exchange. In/Out are
> > the data elements associated with the exchange at any given moment in the
> > route.
> >
> > *When I say pseudo-synchronous it is because Jetty continuations do not
> > hold the calling thread but make callbacks. JMS InOut/request-reply
> > actually set up two queues under the covers, one to send the request and
> > one to send the reply. I'd have to check again on whether the calling
> > thread waits or if a callback mechanism is deployed. Obviously the
> latter
> > is preferable in terms of threading and performance.
> >
> > http://camel.apache.org/request-reply.html
> > http://camel.apache.org/event-message.html
> >
> > Brad
>
>
>
>
>
> --
> View this message in context: http://camel.465427.n5.nabble.
> com/Can-t-understand-what-inOnly-is-doing-tp5787961p5787994.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
>
--
Matt Sicker <bo...@gmail.com>
Re: Can't understand what inOnly is doing
Posted by sim085 <si...@hotmail.com>.
If InOnly works asynchronous then why does it wait for "direct:BBB" to finish
before the next step is executed?
For example take the following code:
[code]
from("jetty:http://localhost:8282/")
.log("Hello From A")
.inOnly("direct:BBB") // asynchronous?
.log("Goodbye From A");
from("direct:BBB")
.log("Hello From B")
.delay(5000)
.log("Goodbye From B");
[/code]
If the [.inOnly("direct:BBB")] was asynchronous then the console should
print "GoodBye From A" before "Goodbye from B" because of the [.delay(5000)]
in route "direct:BBB". However what happens is that the console prints
"Hello From A", "Hello From B", (waits 5 seconds), "Good Bye From B",
"Goodbye From A". (screenshot1 attached).
However beside this there is the fact that the message is not being thrown
away even though I am using the "inOnly" exchange patter. Take the
following:
[code]
from("jetty:http://localhost:8282/")
.transform(constant("AAA")) // Change body of OUT Message.
.inOnly("direct:BBB") // Calling route direct:BBB using inOnly MEP.
.log("I was waiting 'AAA' and got '${in.body}'");
from("direct:BBB")
.transform(constant("BBB")); // Change body of OUT Message.
// But this should be "thrown away" as MEP is inOnly.
[/code]
The above code prints in the logs "I was waiting 'AAA' and got 'BBB'"
(screenshot2 attached). However based on "If it is an InOnly then if there's
a message at the end it is thrown away." shouldn't I have got "I was waiting
'AAA' and got 'AAA'"? Shouldn't the message at the end of route "direct:BBB"
have been thrown away?
Screenshot1:
<http://camel.465427.n5.nabble.com/file/n5787994/screenshot1.png>
Screenshot2:
<http://camel.465427.n5.nabble.com/file/n5787994/screenshot2.png>
Ranx wrote
> InOnly is a fire-and-forget, asynchronous style of messaging. InOut is a
> synchronous or pseudo-synchronous* request-reply messaging as Matt points
> out.
>
> Part of the confusion is about the pattern set on the exchange to indicate
> whether the data flow is InOut or InOnly. The other In/Out on the
> Exchange
> is about the data coming in and going out and is pretty much invariant in
> its existence and data structure. Unfortunately even that's a bit
> misleading terminology as the data is always on the in except when an In
> data on the Exchange follows the route all the way "In" to the last
> endpoint and then if it is an InOut route the Out is what is returned. If
> it is an InOnly then if there's a message at the end it is thrown away.
>
> InOut/InOnly are message flow patterns to set on the exchange. In/Out are
> the data elements associated with the exchange at any given moment in the
> route.
>
> *When I say pseudo-synchronous it is because Jetty continuations do not
> hold the calling thread but make callbacks. JMS InOut/request-reply
> actually set up two queues under the covers, one to send the request and
> one to send the reply. I'd have to check again on whether the calling
> thread waits or if a callback mechanism is deployed. Obviously the latter
> is preferable in terms of threading and performance.
>
> http://camel.apache.org/request-reply.html
> http://camel.apache.org/event-message.html
>
> Brad
--
View this message in context: http://camel.465427.n5.nabble.com/Can-t-understand-what-inOnly-is-doing-tp5787961p5787994.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Can't understand what inOnly is doing
Posted by Brad Johnson <br...@mediadriver.com>.
InOnly is a fire-and-forget, asynchronous style of messaging. InOut is a
synchronous or pseudo-synchronous* request-reply messaging as Matt points
out.
Part of the confusion is about the pattern set on the exchange to indicate
whether the data flow is InOut or InOnly. The other In/Out on the Exchange
is about the data coming in and going out and is pretty much invariant in
its existence and data structure. Unfortunately even that's a bit
misleading terminology as the data is always on the in except when an In
data on the Exchange follows the route all the way "In" to the last
endpoint and then if it is an InOut route the Out is what is returned. If
it is an InOnly then if there's a message at the end it is thrown away.
InOut/InOnly are message flow patterns to set on the exchange. In/Out are
the data elements associated with the exchange at any given moment in the
route.
*When I say pseudo-synchronous it is because Jetty continuations do not
hold the calling thread but make callbacks. JMS InOut/request-reply
actually set up two queues under the covers, one to send the request and
one to send the reply. I'd have to check again on whether the calling
thread waits or if a callback mechanism is deployed. Obviously the latter
is preferable in terms of threading and performance.
http://camel.apache.org/request-reply.html
http://camel.apache.org/event-message.html
Brad
On Sat, Sep 24, 2016 at 2:33 AM, Matt Sicker <bo...@gmail.com> wrote:
> I thought InOnly and InOut had to do with whether or not you were using a
> one-way message or a request-reply message, but I could be wrong here.
>
> On 24 September 2016 at 01:30, cacert <ka...@gmail.com> wrote:
>
> > Perfect question which also confuses me a lot. I wish there could be a
> > upvote
> > button and I hope someone will clarify it soon.
> >
> >
> >
> > --
> > View this message in context: http://camel.465427.n5.nabble.
> > com/Can-t-understand-what-inOnly-is-doing-tp5787961p5787986.html
> > Sent from the Camel - Users mailing list archive at Nabble.com.
> >
>
>
>
> --
> Matt Sicker <bo...@gmail.com>
>
Re: Can't understand what inOnly is doing
Posted by Matt Sicker <bo...@gmail.com>.
I thought InOnly and InOut had to do with whether or not you were using a
one-way message or a request-reply message, but I could be wrong here.
On 24 September 2016 at 01:30, cacert <ka...@gmail.com> wrote:
> Perfect question which also confuses me a lot. I wish there could be a
> upvote
> button and I hope someone will clarify it soon.
>
>
>
> --
> View this message in context: http://camel.465427.n5.nabble.
> com/Can-t-understand-what-inOnly-is-doing-tp5787961p5787986.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
>
--
Matt Sicker <bo...@gmail.com>
Re: Can't understand what inOnly is doing
Posted by cacert <ka...@gmail.com>.
Perfect question which also confuses me a lot. I wish there could be a upvote
button and I hope someone will clarify it soon.
--
View this message in context: http://camel.465427.n5.nabble.com/Can-t-understand-what-inOnly-is-doing-tp5787961p5787986.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Can't understand what inOnly is doing
Posted by sim085 <si...@hotmail.com>.
I am not sure I am following. For example the following page under "Flow of
an exchange through a route" it says "The OUT message from each step is used
as the IN message for the next step. If there is no OUT message then the IN
message is used instead".
Link: http://camel.apache.org/using-getin-or-getout-methods-on-exchange.html
Also the javadoc for ProcessDefinition.transform (which I am using) says
"Adds a processor which sets the body on the OUT message"
Link:
https://camel.apache.org/maven/camel-2.15.0/camel-core/apidocs/org/apache/camel/model/ProcessorDefinition.html#transform(org.apache.camel.Expression)
So based on those two I read my flow as follows; the third line
[.transform(constant("AAA")] sets the body of the OUT message to "AAA". This
becomes the IN message for the next line [.inOnly("direct:BBB")].
Now, if inOnly means that the exchange does not have an OUT message (as per
what I wrote in first post) then shouldn't the IN message be sent to the
next step (based on the first link above)? i.e. - shouldn't the
[.log("${in.body}")] be equal to "AAA" which is the body of the IN message
passed to [.inOnly("direct:BBB")]?
DariusX wrote
> To clarify, your route flows from the initial consumer (jetty), to a
> remove step, then transform, then a "direct" route consisting of another
> transform, and then a log().
>
> All through this sequence, you have an IN body going from step to step
> (sometimes being transformed, but still IN when it reaches the next step
> in the route).
> The OUT would be the response that would be returned all the way back to
> whatever software entity made the initial request via to your jetty
> consumer. But, that OUT is not being set at any point. You could have a
> processor that sets the out.body
>
> Another point to remember is that when you're logging, ${body} is a
> synonym for ${in.body}. You can use ${out.body} to log the body of the OUT
> (but that will be blank in your particular example).
--
View this message in context: http://camel.465427.n5.nabble.com/Can-t-understand-what-inOnly-is-doing-tp5787961p5787980.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Can't understand what inOnly is doing
Posted by DariusX <da...@gmail.com>.
To clarify, your route flows from the initial consumer (jetty), to a remove
step, then transform, then a "direct" route consisting of another transform,
and then a log().
All through this sequence, you have an IN body going from step to step
(sometimes being transformed, but still IN when it reaches the next step in
the route).
The OUT would be the response that would be returned all the way back to
whatever software entity made the initial request via to your jetty
consumer. But, that OUT is not being set at any point. You could have a
processor that sets the out.body
Another point to remember is that when you're logging, ${body} is a synonym
for ${in.body}. You can use ${out.body} to log the body of the OUT (but that
will be blank in your particular example).
--
View this message in context: http://camel.465427.n5.nabble.com/Can-t-understand-what-inOnly-is-doing-tp5787961p5787977.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Can't understand what inOnly is doing
Posted by DariusX <da...@gmail.com>.
Conceptually, an "Out" message is a response, back to the caller.
--
View this message in context: http://camel.465427.n5.nabble.com/Can-t-understand-what-inOnly-is-doing-tp5787961p5787966.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Can't understand what inOnly is doing
Posted by Brad Johnson <br...@mediadriver.com>.
@Sim
Also if you look a little farther down in the SEDA page you'll notice a
section called Use of Request/Reply.
On Tue, Sep 27, 2016 at 11:40 AM, sim085 <si...@hotmail.com> wrote:
> Thanks :)
>
> I had a quick look at the seda component. I can see that it has a check on
> if the exchange is OutCapable or not. This returns true if ExchangePattern
> is InOut.
>
> So I think it is settled. It is up to the component to check the
> ExchangePattern and act accordingly.
>
>
> Claus Ibsen-2 wrote
> > See the seda option waitForTaskToComplete
>
>
>
>
>
> --
> View this message in context: http://camel.465427.n5.nabble.
> com/Can-t-understand-what-inOnly-is-doing-tp5787961p5788125.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
>
Re: Can't understand what inOnly is doing
Posted by sim085 <si...@hotmail.com>.
Thanks :)
I had a quick look at the seda component. I can see that it has a check on
if the exchange is OutCapable or not. This returns true if ExchangePattern
is InOut.
So I think it is settled. It is up to the component to check the
ExchangePattern and act accordingly.
Claus Ibsen-2 wrote
> See the seda option waitForTaskToComplete
--
View this message in context: http://camel.465427.n5.nabble.com/Can-t-understand-what-inOnly-is-doing-tp5787961p5788125.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Can't understand what inOnly is doing
Posted by Claus Ibsen <cl...@gmail.com>.
See the seda option waitForTaskToComplete
On Tue, Sep 27, 2016 at 5:37 PM, sim085 <si...@hotmail.com> wrote:
> This is getting confusing :(
>
> The docs for SEDA seem to say this should always be async.
> Link: http://camel.apache.org/seda.html
>
> They provide the following sample
>
> [code]
> public void configure() throws Exception {
> from("direct:start")
> // send it to the seda queue that is async <<<<<
> .to("seda:next")
> // return a constant response
> .transform(constant("OK"));
>
> from("seda:next").to("mock:result");
> }
>
> Object out = template.requestBody("direct:start", "Hello World");
> assertEquals("OK", out);
> [/code]
>
> However when I add some logs to it I get a pretty synchronous result.
>
> [code]
> import org.apache.camel.ExchangePattern;
> import org.apache.camel.Produce;
> import org.apache.camel.ProducerTemplate;
> import org.apache.camel.builder.RouteBuilder;
> import org.apache.camel.test.junit4.CamelTestSupport;
> import org.junit.Test;
>
> public class AsynchTest extends CamelTestSupport {
> protected RouteBuilder createRouteBuilder() throws Exception {
> return new RouteBuilder() {
>
> @Override
> public void configure() {
>
> from("direct:start")
> .log("AAA: The Body Before SEDA Call is ${in.body}") // Hello World
> // send it to the seda queue that is async
> .to("seda:next")
> // return a constant response
> .log("AAA: Return from BBB!")
> .transform(constant("OK"));
>
> from("seda:next")
> .log("BBB: Going to wait for five seconds!")
> .delay(5000)
> .to("mock:result")
> .log("BBB: I am ready!");
>
> }
> };
> }
>
> @Test
> public void requestReply() {
>
> Object out = super.template.requestBody("direct:start", "Hello World");
> assertEquals("OK", out);
> }
> }
> [/code]
>
> [output]
> [ main] route1 INFO AAA:
> The Body Before SEDA Call is Hello World
> [mel-1) thread #0 - seda://next] route2 INFO BBB:
> Going to wait for five seconds!
> [mel-1) thread #0 - seda://next] route2 INFO BBB: I
> am ready!
> [ main] route1 INFO AAA:
> Return from BBB!
> [/output]
>
> If I set the ExchangePattern to InOnly then it works async.
>
> [output]
> [ main] route1 INFO AAA:
> The Body Before SEDA Call is Hello World
> [ main] route1 INFO AAA:
> Return from BBB!
> ...
> [mel-1) thread #0 - seda://next] route2 INFO BBB:
> Going to wait for five seconds!
> ...
> [mel-1) thread #0 - seda://next] route2 INFO BBB: I
> am ready!
> [/output]
>
>
>
> sim085 wrote
>> I have changed the code a little and ran the test again. From what I can
>> see the SEDA endpoint acts correctly to the InOut and InOnly
>> ExchangePattern, i.e. - acts asynchronously when called with InOnly and
>> synchronously when called with InOut.
>
>
>
>
>
> --
> View this message in context: http://camel.465427.n5.nabble.com/Can-t-understand-what-inOnly-is-doing-tp5787961p5788123.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
--
Claus Ibsen
-----------------
http://davsclaus.com @davsclaus
Camel in Action 2: https://www.manning.com/ibsen2
Re: Can't understand what inOnly is doing
Posted by sim085 <si...@hotmail.com>.
This is getting confusing :(
The docs for SEDA seem to say this should always be async.
Link: http://camel.apache.org/seda.html
They provide the following sample
[code]
public void configure() throws Exception {
from("direct:start")
// send it to the seda queue that is async <<<<<
.to("seda:next")
// return a constant response
.transform(constant("OK"));
from("seda:next").to("mock:result");
}
Object out = template.requestBody("direct:start", "Hello World");
assertEquals("OK", out);
[/code]
However when I add some logs to it I get a pretty synchronous result.
[code]
import org.apache.camel.ExchangePattern;
import org.apache.camel.Produce;
import org.apache.camel.ProducerTemplate;
import org.apache.camel.builder.RouteBuilder;
import org.apache.camel.test.junit4.CamelTestSupport;
import org.junit.Test;
public class AsynchTest extends CamelTestSupport {
protected RouteBuilder createRouteBuilder() throws Exception {
return new RouteBuilder() {
@Override
public void configure() {
from("direct:start")
.log("AAA: The Body Before SEDA Call is ${in.body}") // Hello World
// send it to the seda queue that is async
.to("seda:next")
// return a constant response
.log("AAA: Return from BBB!")
.transform(constant("OK"));
from("seda:next")
.log("BBB: Going to wait for five seconds!")
.delay(5000)
.to("mock:result")
.log("BBB: I am ready!");
}
};
}
@Test
public void requestReply() {
Object out = super.template.requestBody("direct:start", "Hello World");
assertEquals("OK", out);
}
}
[/code]
[output]
[ main] route1 INFO AAA:
The Body Before SEDA Call is Hello World
[mel-1) thread #0 - seda://next] route2 INFO BBB:
Going to wait for five seconds!
[mel-1) thread #0 - seda://next] route2 INFO BBB: I
am ready!
[ main] route1 INFO AAA:
Return from BBB!
[/output]
If I set the ExchangePattern to InOnly then it works async.
[output]
[ main] route1 INFO AAA:
The Body Before SEDA Call is Hello World
[ main] route1 INFO AAA:
Return from BBB!
...
[mel-1) thread #0 - seda://next] route2 INFO BBB:
Going to wait for five seconds!
...
[mel-1) thread #0 - seda://next] route2 INFO BBB: I
am ready!
[/output]
sim085 wrote
> I have changed the code a little and ran the test again. From what I can
> see the SEDA endpoint acts correctly to the InOut and InOnly
> ExchangePattern, i.e. - acts asynchronously when called with InOnly and
> synchronously when called with InOut.
--
View this message in context: http://camel.465427.n5.nabble.com/Can-t-understand-what-inOnly-is-doing-tp5787961p5788123.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Can't understand what inOnly is doing
Posted by sim085 <si...@hotmail.com>.
@Ranx, I had another look at your code. I have changed the code a little and
ran the test again. From what I can see the SEDA endpoint acts correctly to
the InOut and InOnly ExchangePattern, i.e. - acts asynchronously when called
with InOnly and synchronously when called with InOut.
Changed code and reproduced below:
[code]
import org.apache.camel.ExchangePattern;
import org.apache.camel.Produce;
import org.apache.camel.ProducerTemplate;
import org.apache.camel.builder.RouteBuilder;
import org.apache.camel.test.junit4.CamelTestSupport;
import org.junit.Test;
public class AsynchTest extends CamelTestSupport {
protected RouteBuilder createRouteBuilder() throws Exception {
return new RouteBuilder() {
@Override
public void configure() {
from("direct:AAA")
.to("seda:BBB")
.log("AAA: Current Message is '${body}'");
from("seda:BBB")
.transform(constant("BBB"))
.log("BBB: Current Message is '${body}'");
}
};
}
@Produce(uri = "direct:AAA")
protected ProducerTemplate producer;
@Test public void fireAndForget() {
producer.sendBody("AAA_FAF");
/*
* This logs:
*
* INFO AAA: Current Message is 'AAA_FAF'
* INFO BBB: Current Message is 'BBB'
*
*/
}
@Test public void requestReply() {
String result = (String) producer.requestBody("AAA_RR");
System.out.println("Result: "+ result);
/*
* This logs:
*
* INFO BBB: Current Message is 'BBB'
* INFO AAA: Current Message is 'BBB'
* Result: BBB
*
*/
}
}
[/code]
Ranx wrote
> If you look at the Unit test I posted earlier on that thread or even
> copy/paste it into a test class and run it you'll notice that the
> sub-route
> invocation behavior changes depending on whether the initial invocation of
> the very first endpoint is fire and forget or request/reply.
--
View this message in context: http://camel.465427.n5.nabble.com/Can-t-understand-what-inOnly-is-doing-tp5787961p5788118.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Can't understand what inOnly is doing
Posted by Brad Johnson <br...@mediadriver.com>.
I'm not sure on point 3 either and the tests didn't appear that way. If
you look at the Unit test I posted earlier on that thread or even
copy/paste it into a test class and run it you'll notice that the sub-route
invocation behavior changes depending on whether the initial invocation of
the very first endpoint is fire and forget or request/reply. On a
request/reply (requestBody) the sub-route even with SEDA is invoked before
the parent route completes. So the mutation of the value there appears in
the final log statement of the parent route. On a fire and forget
(sendBody) then the parent route will complete with the same value you sent
in and you'll see it log that very same value. Then the sub-route executes.
The exchange Id changes when going from one route to another but I don't
think that implies a deep clone and I'd have to check it. So essentially
when you pass the Exchange to the sub-route, you are passing a big hashmap
with headers, properties and an In Message and a null Out Message. So when
you change the value of the body in the sub-route in a request/reply
you'll see it show up in the final log statement of the parent route.
Since I almost never uses Processors or directly manipulate Exchanges there
are likely a number of folks who can chime in and give you a better
explanation.
On Tue, Sep 27, 2016 at 5:22 AM, sim085 <si...@hotmail.com> wrote:
>
> Just want to highlight that I have my reservations on point 3.
>
> From what I can see the ExchangePattern parameter doesn't determine
> anything. The same applies for calling something using inOut or inOnly.
>
> Again from what I can see from the examples I have tried out, what
> determines if the parent route will wait or not for the sub-route to
> complete, or if the message used by the parent is the IN passed to the
> sub-route or the OUT of the sub-route ALL DEPENDS on if the sub-route, i.e.
> - if the sub route care less about the Exchange Pattern with which it has
> been called or not.
>
> I do not know if anyone can share an example where this is not so?
>
>
> DariusX wrote
> > 3. The MEP used for the "sub-route" determines whether the "parent" route
> > will wait for the "sub-route" and use the out-message of that sub-route
> as
> > the in-message to its next step.
>
>
>
>
>
> --
> View this message in context: http://camel.465427.n5.nabble.
> com/Can-t-understand-what-inOnly-is-doing-tp5787961p5788103.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
>
Re: Can't understand what inOnly is doing
Posted by Brad Johnson <br...@mediadriver.com>.
@sim
That's what I see as well. Which is why I decided to see if the short
circuit using inOnly to call the seda queue would change behavior and it
does.
On Tue, Sep 27, 2016 at 10:28 AM, Brad Johnson <brad.johnson@mediadriver.com
> wrote:
> Going back to this unit test I added another route so I could comment it
> in or out for different tests. If the inOnly is used to call the seda route
> then it operates exactly the same regardless of whether the sendBody
> (fire/forget) is used or the requestBody (request/reply) is used to
> initiate the call. If I comment that out and put the to in then it runs
> differently for the two different calls.
>
> The reason I've never run into this before is I'll use a handler that is
> just a Java object for things like incoming web service calls. If I want
> it to operate async to send it or its contents to another route I'll simply
> fire it with sendBody. As an example if myHandlerPojo has a method on it
> called doHandleMessage(MyPojoMessage message) and the MyPojoMessage is what
> is unmarshaled from the REST or SOAP service, then the route will invoke my
> handler via reflection. If the MyPojoMessage contains a list of something
> like Records (or whatever you might call it) I'll usually just spin through
> it and send each one of those with sendBody to the seda queue for further
> processing - asynchronously. After sending those Record objects to the
> seda queue I'll return whatever the service call is expecting back "OK" for
> example or a message wrapper for that.
>
> public class AsynchTest extends CamelTestSupport {
>
> protected RoutesBuilder createRouteBuilder() throws Exception {
> return new RouteBuilder() {
> @Override
> public void configure() {
> from("direct:in").inOnly("seda:bbb").log("${exchangeId}").log("End
> Direct: ${body}");
> //from("direct:in").to("seda:bbb").log("${exchangeId}").log("End Direct:
> ${body}");
> from("seda:bbb").setBody(simple("bbb")).log("${exchangeId}").log("End
> SEDA: ${body}");
> }
> };
> }
>
> @Produce(uri = "direct:in")
> protected ProducerTemplate producer;
>
> @Test
> public void fireAndForget() {
>
> producer.sendBody("aaa");
>
> }
> @Test
> public void requestReply() {
>
> String result = (String) producer.requestBody("aaa");
> System.out.println("Result: "+ result);
>
> }
>
> }
>
>
> On Tue, Sep 27, 2016 at 10:11 AM, DariusX <da...@gmail.com> wrote:
>
>> sim085 wrote
>> > Just want to highlight that I have my reservations on point 3.
>>
>> I assume you're right that it is the responsibility of each component to
>> read the MEP value and act on it if it needs to.
>> Point #4 says that the MEP indicator on the exchange will not impact some
>> routes.
>> In other words, the framework leaves it to the component to decide whether
>> the MEP is meaningful to it.
>>
>> I too wish someone could either confirm this or provide a counter example.
>>
>> I created a Java class to test the behavior, here:
>> https://github.com/DariusX/CamelTests/blob/master/CamelTests
>> /src/main/java/com/xby2/dariusx/InOutTest.java
>>
>>
>>
>> --
>> View this message in context: http://camel.465427.n5.nabble.
>> com/Can-t-understand-what-inOnly-is-doing-tp5787961p5788119.html
>> Sent from the Camel - Users mailing list archive at Nabble.com.
>>
>
>
Re: Can't understand what inOnly is doing
Posted by Brad Johnson <br...@mediadriver.com>.
Going back to this unit test I added another route so I could comment it in
or out for different tests. If the inOnly is used to call the seda route
then it operates exactly the same regardless of whether the sendBody
(fire/forget) is used or the requestBody (request/reply) is used to
initiate the call. If I comment that out and put the to in then it runs
differently for the two different calls.
The reason I've never run into this before is I'll use a handler that is
just a Java object for things like incoming web service calls. If I want
it to operate async to send it or its contents to another route I'll simply
fire it with sendBody. As an example if myHandlerPojo has a method on it
called doHandleMessage(MyPojoMessage message) and the MyPojoMessage is what
is unmarshaled from the REST or SOAP service, then the route will invoke my
handler via reflection. If the MyPojoMessage contains a list of something
like Records (or whatever you might call it) I'll usually just spin through
it and send each one of those with sendBody to the seda queue for further
processing - asynchronously. After sending those Record objects to the
seda queue I'll return whatever the service call is expecting back "OK" for
example or a message wrapper for that.
public class AsynchTest extends CamelTestSupport {
protected RoutesBuilder createRouteBuilder() throws Exception {
return new RouteBuilder() {
@Override
public void configure() {
from("direct:in").inOnly("seda:bbb").log("${exchangeId}").log("End Direct:
${body}");
//from("direct:in").to("seda:bbb").log("${exchangeId}").log("End Direct:
${body}");
from("seda:bbb").setBody(simple("bbb")).log("${exchangeId}").log("End SEDA:
${body}");
}
};
}
@Produce(uri = "direct:in")
protected ProducerTemplate producer;
@Test
public void fireAndForget() {
producer.sendBody("aaa");
}
@Test
public void requestReply() {
String result = (String) producer.requestBody("aaa");
System.out.println("Result: "+ result);
}
}
On Tue, Sep 27, 2016 at 10:11 AM, DariusX <da...@gmail.com> wrote:
> sim085 wrote
> > Just want to highlight that I have my reservations on point 3.
>
> I assume you're right that it is the responsibility of each component to
> read the MEP value and act on it if it needs to.
> Point #4 says that the MEP indicator on the exchange will not impact some
> routes.
> In other words, the framework leaves it to the component to decide whether
> the MEP is meaningful to it.
>
> I too wish someone could either confirm this or provide a counter example.
>
> I created a Java class to test the behavior, here:
> https://github.com/DariusX/CamelTests/blob/master/
> CamelTests/src/main/java/com/xby2/dariusx/InOutTest.java
>
>
>
> --
> View this message in context: http://camel.465427.n5.nabble.
> com/Can-t-understand-what-inOnly-is-doing-tp5787961p5788119.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
>
Re: Can't understand what inOnly is doing
Posted by DariusX <da...@gmail.com>.
sim085 wrote
> Just want to highlight that I have my reservations on point 3.
I assume you're right that it is the responsibility of each component to
read the MEP value and act on it if it needs to.
Point #4 says that the MEP indicator on the exchange will not impact some
routes.
In other words, the framework leaves it to the component to decide whether
the MEP is meaningful to it.
I too wish someone could either confirm this or provide a counter example.
I created a Java class to test the behavior, here:
https://github.com/DariusX/CamelTests/blob/master/CamelTests/src/main/java/com/xby2/dariusx/InOutTest.java
--
View this message in context: http://camel.465427.n5.nabble.com/Can-t-understand-what-inOnly-is-doing-tp5787961p5788119.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Can't understand what inOnly is doing
Posted by sim085 <si...@hotmail.com>.
Just want to highlight that I have my reservations on point 3.
From what I can see the ExchangePattern parameter doesn't determine
anything. The same applies for calling something using inOut or inOnly.
Again from what I can see from the examples I have tried out, what
determines if the parent route will wait or not for the sub-route to
complete, or if the message used by the parent is the IN passed to the
sub-route or the OUT of the sub-route ALL DEPENDS on if the sub-route, i.e.
- if the sub route care less about the Exchange Pattern with which it has
been called or not.
I do not know if anyone can share an example where this is not so?
DariusX wrote
> 3. The MEP used for the "sub-route" determines whether the "parent" route
> will wait for the "sub-route" and use the out-message of that sub-route as
> the in-message to its next step.
--
View this message in context: http://camel.465427.n5.nabble.com/Can-t-understand-what-inOnly-is-doing-tp5787961p5788103.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Can't understand what inOnly is doing
Posted by sim085 <si...@hotmail.com>.
This is also my understanding and likewise I would like to know if this
interpretation is right or wrong.
That said, don't these points imply that the Exchange Pattern is a FLAG
which a target a end point can ignore or wrap logic around?
DariusX wrote
> 3. The MEP used for the "sub-route" determines whether the "parent" route
> will wait for the "sub-route" and use the out-message of that sub-route as
> the in-message to its next step.
>
> 4. By implication, the MEP of the "sub-route" will not have an effect if
> the "sub-route" is always synchronous (or always asynchronous). If the
> "sub-route" is always synchronous, it basically does not support being
> called with inOnly(). If the sub-route is always asynchronous, it does not
> support being called with inOut(). Setting the MEP has no impact on such
> routes.
>
> 5. Going back to the original question: since "direct:xyz" is always
> synchronous, it always works as if it is being called with InOut,
> regardless of the MEP on the route.
--
View this message in context: http://camel.465427.n5.nabble.com/Can-t-understand-what-inOnly-is-doing-tp5787961p5788102.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Can't understand what inOnly is doing
Posted by Brad Johnson <br...@mediadriver.com>.
On point 5. from the tests I did it appears that direct:xyz is not
necessarily InOut/InOnly. Since the producer template with sendBody was an
InOnly the behavior of the routes downstream behaved differently than when
I used the requestBody which starts as an InOut.
Most of the time when using a seda queue I'm doing it in the context of
something like a file reader that is getting tokenized and then
unmarshalled via something like Beanio so I presume that it is InOnly as in
from("file://dir/myfile.txt") and once in the seda queue I commonly use a
thread pool to allow for better processing/throughput. When I get
request/replies I'm usually using direct/direct-vm. From the results of
the tests and further reading it would appear that in InOut at the start of
the route is going to dictated that the sub-route with seda is going to
finish processing before the rest of the calling route is executed.
I'd have to think about the implications though of trying to use the seda
route to process a number of individual items with returns. In other
words, you get a List<MyPojo> and spin through it sending each MyPojo to
the seda queue expecting a result back. But you'd get each MyPojo response
back separately and would have to collect them until one knew that all the
processing was done. A splitter/aggregator combo might work for that I
just haven't tried it. Perhaps I'll try it in the future if the need
arises. One could also have a collection in the header to add responses to
but I'd have to give it a deep think to see how practical that would be.
Perhaps a better developer than I could help you out with that. Or at
least a developer with more experience with that pattern.
On Mon, Sep 26, 2016 at 2:35 PM, DariusX <da...@gmail.com> wrote:
> Thanks for the all the exploration and explanation.
> I offer this summary, for comment:
>
> 1. The template starts the route with a Message Exchange Pattern (MEP)
> "InOnly" or "InOut", depending on whether we use template.sendBody() or
> template.requestBody() respectively
>
> 2. The inOut() and inOnly() set the Message Exchange Pattern (MEP) for
> whatever they're wrapping. If a to() were used instead, the MEP of the
> "sub-route" would be the same as the MEP for the "parent" route. So, using
> inOnly() or inOut() makes sense in a context where one wishes to be
> explicit
> for the "sub-route".
>
> 3. The MEP used for the "sub-route" determines whether the "parent" route
> will wait for the "sub-route" and use the out-message of that sub-route as
> the in-message to its next step.
>
> 4. By implication, the MEP of the "sub-route" will not have an effect if
> the
> "sub-route" is always synchronous (or always asynchronous). If the
> "sub-route" is always synchronous, it basically does not support being
> called with inOnly(). If the sub-route is always asynchronous, it does not
> support being called with inOut(). Setting the MEP has no impact on such
> routes.
>
> 5. Going back to the original question: since "direct:xyz" is always
> synchronous, it always works as if it is being called with InOut,
> regardless
> of the MEP on the route.
>
> I'd appreciate being told if I've got some of that wrong.
>
>
>
>
> --
> View this message in context: http://camel.465427.n5.nabble.
> com/Can-t-understand-what-inOnly-is-doing-tp5787961p5788072.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
>
Re: Can't understand what inOnly is doing
Posted by DariusX <da...@gmail.com>.
Thanks for the all the exploration and explanation.
I offer this summary, for comment:
1. The template starts the route with a Message Exchange Pattern (MEP)
"InOnly" or "InOut", depending on whether we use template.sendBody() or
template.requestBody() respectively
2. The inOut() and inOnly() set the Message Exchange Pattern (MEP) for
whatever they're wrapping. If a to() were used instead, the MEP of the
"sub-route" would be the same as the MEP for the "parent" route. So, using
inOnly() or inOut() makes sense in a context where one wishes to be explicit
for the "sub-route".
3. The MEP used for the "sub-route" determines whether the "parent" route
will wait for the "sub-route" and use the out-message of that sub-route as
the in-message to its next step.
4. By implication, the MEP of the "sub-route" will not have an effect if the
"sub-route" is always synchronous (or always asynchronous). If the
"sub-route" is always synchronous, it basically does not support being
called with inOnly(). If the sub-route is always asynchronous, it does not
support being called with inOut(). Setting the MEP has no impact on such
routes.
5. Going back to the original question: since "direct:xyz" is always
synchronous, it always works as if it is being called with InOut, regardless
of the MEP on the route.
I'd appreciate being told if I've got some of that wrong.
--
View this message in context: http://camel.465427.n5.nabble.com/Can-t-understand-what-inOnly-is-doing-tp5787961p5788072.html
Sent from the Camel - Users mailing list archive at Nabble.com.