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 <boa...@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 <sim...@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 <boa...@gmail.com>
>
