You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@camel.apache.org by Babak Vahdat <ba...@swissonline.ch> on 2013/05/01 06:23:13 UTC

Re: camel-quickfix RequestReplyExample java.io.IOException

Hi Steve,

Sorry for the late answer but just for the record and also maybe other users
who may follow this thread:

The reason for the behavior you were observing has nothing to do with the
MEP itself but a bug being already fixed:

   https://issues.apache.org/jira/browse/CAMEL-5979

So that if yo would try the same now (e.g on the trunk code) then the
behaviour you're describing below is not given anymore.

Babak


stevebate wrote
> On Feb 27, 2013, at 3:12 AM, "Babak Vahdat [via Camel]" &lt;

> ml-node+s465427n5728204h85@.nabble

> &gt; wrote:
> 
>> Hi Steve 
>> 
>> Thanks for looking into this. Unfortunately the provided patch causes
>> regressions by some pre-existing tests of this component. I've provided
>> the details of this into the ticket itself, so let's continue the
>> conversation inside JIRA itself to avoid making noise here @ the user
>> forum. 
> 
> Sorry. I should have run the unit tests before submitting the patch. I've
> submitted an updated patch with changes to the unit test mock setup for
> the new Exchange copy behavior and the sessionID reversal in the
> MessagePredicate. I agree we can continue any patch-related discussion
> using Jira. However, the following discussion might be of general
> interest.
> 
>> And regarding your surprise maybe the following thread could be helpful
>> for a better understanding: 
>> 
>> http://camel.465427.n5.nabble.com/About-what-to-do-with-the-Response-retrieved-through-a-Producer-when-the-Exchange-is-NOT-out-capable-td5713946.html
>> 
>> In general if the MEP is InOnly and a service invocation (through a Camel
>> Producer) returns a reply, then a good practice is to set the reply as
>> the body of the IN message. This would make the next processor in chain
>> to make use of this IN object as it say here: 
> 
> This is confusing to me because the Exchange is now InOut, not InOnly. I
> did some experimentation and found that this route,
> 
>  
> from("quickfix:examples/inprocess.cfg?sessionID=FIX.4.2:MARKET->TRADER&exchangePattern=InOut")
>    
> .filter(header(QuickfixjEndpoint.MESSAGE_TYPE_KEY).isEqualTo(MsgType.ORDER_STATUS_REQUEST))
>     .bean(new MarketOrderStatusService())
>     .bean(new QuickfixjMessageJsonPrinter());
> 
> required the Exchange copy for the InOut MEP because the inbound message
> is overwritten by subsequent processors. However, 
> the following route does not require the copy (the
> QuickfixjMessageJsonPrinter bean has been removed).
> 
>  
> from("quickfix:examples/inprocess.cfg?sessionID=FIX.4.2:MARKET->TRADER&exchangePattern=InOut")
>    
> .filter(header(QuickfixjEndpoint.MESSAGE_TYPE_KEY).isEqualTo(MsgType.ORDER_STATUS_REQUEST))
>     .bean(new MarketOrderStatusService());
>     
> Does this mean that the QuickfixjConsumer is sometimes required to copy
> the inbound Exchange (InOut MEP) and sometimes not,
> depending on the route components that follow it? If so, the safe behavior
> is to always copy the Exchange, but it seems that it should
> logically not need to do that for an InOut MEP.
> 
>> if there is no out message then the in message is used instead
>> http://camel.apache.org/using-getin-or-getout-methods-on-exchange.html
>>





--
View this message in context: http://camel.465427.n5.nabble.com/camel-quickfix-RequestReplyExample-java-io-IOException-tp5723769p5731828.html
Sent from the Camel - Users mailing list archive at Nabble.com.