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>
