On Feb 25, 2013, at 2:21 PM, Babak Vahdat [via Camel] <ml-node+s465427n5728116...@n5.nabble.com> 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-tp5723769p5728201.html Sent from the Camel - Users mailing list archive at Nabble.com.
