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 On Sat, Sep 24, 2016 at 2:33 AM, Matt Sicker <boa...@gmail.com> wrote: > I thought InOnly and InOut had to do with whether or not you were using a > one-way message or a request-reply message, but I could be wrong here. > > On 24 September 2016 at 01:30, cacert <kasims...@gmail.com> wrote: > > > Perfect question which also confuses me a lot. I wish there could be a > > upvote > > button and I hope someone will clarify it soon. > > > > > > > > -- > > View this message in context: http://camel.465427.n5.nabble. > > com/Can-t-understand-what-inOnly-is-doing-tp5787961p5787986.html > > Sent from the Camel - Users mailing list archive at Nabble.com. > > > > > > -- > Matt Sicker <boa...@gmail.com> >
