camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Babak Vahdat <babak.vah...@swissonline.ch>
Subject Re: camel-quickfix RequestReplyExample java.io.IOException
Date Wed, 27 Feb 2013 08:12:09 GMT
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.

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:


> 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

Babak


stevebate wrote
> On Feb 25, 2013, at 2:21 PM, Babak Vahdat [via Camel] &lt;

> ml-node+s465427n5728116h57@.nabble

> &gt; wrote:
>> As I did *not* backport the fix for CAMEL-5861 to this branch (because it
>> was/is not a supported version anymore). However the example works
>> properly on the 2.10.x branch as well as trunk with the proper JSON
>> outputs for both the request (OrderStatusRequest) as well as the reply
>> (ExecutionReport). But as because the QuickfixjConsumer doesn't honor the
>> MEP (apparently it used to honor this at the time you donated it) there
>> is currently no way to provide the ExecutionReport JSON output as the
>> HTTP reply itself. Please take a look at the log output I've added to the
>> example (the first comment of the ticket): 
>> 
>> https://issues.apache.org/jira/browse/CAMEL-5880
>> 
>> As you see *although* we ask for the exchangePattern=InOut option through
>> the URI the logged message shows an effective InOnly MEP! 
> 
> Hello Babak,
> 
> I've found several issues with the example. I have a patch that fixes the
> InOnly MEP issue. I also found an issue with the MessagePredicate. It was
> reversing the FIX Session ID so the MessageCorrelator wasn't working
> correctly. I was surprised to see that when the component processes an
> exchange (QuickfixjConsumer.onExchange), Camel overwrites the inbound
> message in the exchange with the result of the service invocation. I
> copied the inbound exchange and restored the "In" before sending the
> service response. Finally, I reverted the modification to the message
> correlation so that the ExecutionReport is used instead of the
> OrderStatusRequest (2.10.x branch). 
> 
> The IOException was being raised because the ExecutionReport result was
> never correlated to the OrderStatusRequest. This was because of the InOut
> MEP issue and the problem with the MessagePredicate that is used for the
> correlation. The HTTP request didn't have a result to return so that
> caused the 500 server error after the message correlation timed out.
> 
> With my patch, the example appears to fully work. I'll attach it to the
> Jira issue for your review.
> 
>> Please be aware that I've got no expertise about the QuickFixJ framework
>> or the FIX protocol itself and the fixes I've provided here are based on
>> a best effort basis to make things work again (no HTTP 500 anymore). But
>> having you as the founder of QuickFixJ and the Guru here in this thread
>> makes me really happy! So please take a look at the stuff here to see if
>> we could do even better. 
> 
> I have very little experience with Camel, so hopefully we can help each
> other on this task.
> 
>> Last but not least that would be just awesome if we could make a proper
>> Camel example module out of these classes which are currently under the
>> path src/test/java of the camel-quickfix module itself, that's to make
>> them like the other examples we have: 
> 
> I agree, but I'm not sure if I'll have time to make this change. We'll
> see.
> 
> Steve





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

Mime
View raw message