[Quickfix-developers] Processing missed messages

[Robin S. <Rob...@re...>]

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.