I've noticed the fire and forget only works with seda end point called with
inOnly.
On Sep 26, 2016 02:31, "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>
> >>
> >
> >
>
