@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>
>>
>
>
