[Quickfix-developers] Processing missed messages
Brought to you by:
orenmnero
|
From: Robin S. <Rob...@re...> - 2006-04-11 23:29:25
|
Hi, =20 working with QuickFixJ 1.0.0b3. I have a scenario where quickfix is not behaving as I would expect it to, would appreciate comment on whether my expectation is reasonable. =20 1. starting at an arbitary point in the session, my application receives message seq nums 205 and 206 in rapid succession from the target such that they have been received by the quickfixj comms code but NOT yet posted to my application. =20 2. message number 205 is posted to my application in fromApp =20 3. while processing 205 my application dies =20 4. the application is restarted and it receives a logon from the target with seqnum of 207. I observe the following in the console : =20 11/04/06 22:21:29.757 GMT [QFJ Socket Acceptor 131303f] FIX Event : FIX.4.2:J75515N->x Received logon response 11/04/06 22:21:29.757 GMT [QFJ Socket Acceptor 131303f] FIX Event : FIX.4.2:J75515N->x MsgSeqNum too high, expecting 205 but received 207 11/04/06 22:21:29.807 GMT [QFJ Socket Acceptor 131303f] FIX Event : Re-Sync Target MsgSeqNum to 207 11/04/06 22:21:29.838 GMT [QFJ Socket Acceptor 131303f] FIX toAdmin : FIX.4.2:J75515N->x ResendRequest ... 11/04/06 22:21:29.988 GMT [QFJ Socket Acceptor 131303f] FIX Event : FIX.4.2:J75515N->x Sent ResendRequest FROM: 207 TO: 0 =20 indicating quickfix on behalf of my application has requested the missing messages. All great so far. =20 5. The next I see however in the console is : =20 11/04/06 22:21:30.338 GMT [QFJ Socket Acceptor 131303f] FIX Event : FIX.4.2:J75515N->x Processing QUEUED message: 207 because quickfix has worked through the resent messages and caught up with where the target system expects it to be. =20 My problem with this is that my application did not get a chance to process 205 again (it never completed the first time) and never even got to see 206. I would have hoped that quickfix would act like a message queue implementation in this case and ensure that the application layer got to see every message at least once and in order. =20 I have looked through the source and, although I haven't debugged the above, it looks like isTargetTooLow->doTargetTooLow in Session.verify(...) could be responsible for swallowing these messages. It looks deliberate though, anyone help me by explaining why? =20 -Rob To find out more about Reuters visit www.about.reuters.com Any views expressed in this message are those of the individual sender, exc= ept where the sender specifically states them to be the views of Reuters Lt= d. |