@sim That's what I see as well. Which is why I decided to see if the short circuit using inOnly to call the seda queue would change behavior and it does.
On Tue, Sep 27, 2016 at 10:28 AM, Brad Johnson <[email protected] > wrote: > Going back to this unit test I added another route so I could comment it > in or out for different tests. If the inOnly is used to call the seda route > then it operates exactly the same regardless of whether the sendBody > (fire/forget) is used or the requestBody (request/reply) is used to > initiate the call. If I comment that out and put the to in then it runs > differently for the two different calls. > > The reason I've never run into this before is I'll use a handler that is > just a Java object for things like incoming web service calls. If I want > it to operate async to send it or its contents to another route I'll simply > fire it with sendBody. As an example if myHandlerPojo has a method on it > called doHandleMessage(MyPojoMessage message) and the MyPojoMessage is what > is unmarshaled from the REST or SOAP service, then the route will invoke my > handler via reflection. If the MyPojoMessage contains a list of something > like Records (or whatever you might call it) I'll usually just spin through > it and send each one of those with sendBody to the seda queue for further > processing - asynchronously. After sending those Record objects to the > seda queue I'll return whatever the service call is expecting back "OK" for > example or a message wrapper for that. > > public class AsynchTest extends CamelTestSupport { > > protected RoutesBuilder createRouteBuilder() throws Exception { > return new RouteBuilder() { > @Override > public void configure() { > from("direct:in").inOnly("seda:bbb").log("${exchangeId}").log("End > Direct: ${body}"); > //from("direct:in").to("seda:bbb").log("${exchangeId}").log("End Direct: > ${body}"); > from("seda:bbb").setBody(simple("bbb")).log("${exchangeId}").log("End > SEDA: ${body}"); > } > }; > } > > @Produce(uri = "direct:in") > protected ProducerTemplate producer; > > @Test > public void fireAndForget() { > > producer.sendBody("aaa"); > > } > @Test > public void requestReply() { > > String result = (String) producer.requestBody("aaa"); > System.out.println("Result: "+ result); > > } > > } > > > On Tue, Sep 27, 2016 at 10:11 AM, DariusX <[email protected]> wrote: > >> sim085 wrote >> > Just want to highlight that I have my reservations on point 3. >> >> I assume you're right that it is the responsibility of each component to >> read the MEP value and act on it if it needs to. >> Point #4 says that the MEP indicator on the exchange will not impact some >> routes. >> In other words, the framework leaves it to the component to decide whether >> the MEP is meaningful to it. >> >> I too wish someone could either confirm this or provide a counter example. >> >> I created a Java class to test the behavior, here: >> https://github.com/DariusX/CamelTests/blob/master/CamelTests >> /src/main/java/com/xby2/dariusx/InOutTest.java >> >> >> >> -- >> View this message in context: http://camel.465427.n5.nabble. >> com/Can-t-understand-what-inOnly-is-doing-tp5787961p5788119.html >> Sent from the Camel - Users mailing list archive at Nabble.com. >> > >
