On point 5. from the tests I did it appears that direct:xyz is not
necessarily InOut/InOnly. Since the producer template with sendBody was an
InOnly the behavior of the routes downstream behaved differently than when
I used the requestBody which starts as an InOut.
Most of the time when using a seda queue I'm doing it in the context of
something like a file reader that is getting tokenized and then
unmarshalled via something like Beanio so I presume that it is InOnly as in
from("file://dir/myfile.txt") and once in the seda queue I commonly use a
thread pool to allow for better processing/throughput. When I get
request/replies I'm usually using direct/direct-vm. From the results of
the tests and further reading it would appear that in InOut at the start of
the route is going to dictated that the sub-route with seda is going to
finish processing before the rest of the calling route is executed.
I'd have to think about the implications though of trying to use the seda
route to process a number of individual items with returns. In other
words, you get a List<MyPojo> and spin through it sending each MyPojo to
the seda queue expecting a result back. But you'd get each MyPojo response
back separately and would have to collect them until one knew that all the
processing was done. A splitter/aggregator combo might work for that I
just haven't tried it. Perhaps I'll try it in the future if the need
arises. One could also have a collection in the header to add responses to
but I'd have to give it a deep think to see how practical that would be.
Perhaps a better developer than I could help you out with that. Or at
least a developer with more experience with that pattern.
On Mon, Sep 26, 2016 at 2:35 PM, DariusX <dariuscoo...@gmail.com> wrote:
> Thanks for the all the exploration and explanation.
> I offer this summary, for comment:
>
> 1. The template starts the route with a Message Exchange Pattern (MEP)
> "InOnly" or "InOut", depending on whether we use template.sendBody() or
> template.requestBody() respectively
>
> 2. The inOut() and inOnly() set the Message Exchange Pattern (MEP) for
> whatever they're wrapping. If a to() were used instead, the MEP of the
> "sub-route" would be the same as the MEP for the "parent" route. So, using
> inOnly() or inOut() makes sense in a context where one wishes to be
> explicit
> for the "sub-route".
>
> 3. The MEP used for the "sub-route" determines whether the "parent" route
> will wait for the "sub-route" and use the out-message of that sub-route as
> the in-message to its next step.
>
> 4. By implication, the MEP of the "sub-route" will not have an effect if
> the
> "sub-route" is always synchronous (or always asynchronous). If the
> "sub-route" is always synchronous, it basically does not support being
> called with inOnly(). If the sub-route is always asynchronous, it does not
> support being called with inOut(). Setting the MEP has no impact on such
> routes.
>
> 5. Going back to the original question: since "direct:xyz" is always
> synchronous, it always works as if it is being called with InOut,
> regardless
> of the MEP on the route.
>
> I'd appreciate being told if I've got some of that wrong.
>
>
>
>
> --
> View this message in context: http://camel.465427.n5.nabble.
> com/Can-t-understand-what-inOnly-is-doing-tp5787961p5788072.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
>
