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 <brad.john...@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.john...@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 <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>
>>>
>>
>>
>
