@Sashika
I was just looking at that again right before I read your email. I created
and added a quick unit test to the thread. Basically the producer template
does inOnly when you do a sendBody and InOut when requestBody is used. If
it weren't already getting late I'd probably log the Exchange In/Out bodies
and see how they change.
Which makes sense because I know from the documents that you can modify the
behavior of certain endpoints that call the seda route to determine whether
it is request/reply or fire/forget. If memory serves in the docs there's a
bit showing how to modify a mina endpoint in to get the results of the SEDA
queue back.
On Sun, Sep 25, 2016 at 11:04 PM, Sashika <sashik...@gmail.com> wrote:
> 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>
> > >>
> > >
> > >
> >
>
