Re: [Quickfixj-users] Managing SeqNo manually

[jim_b_o <jam...@co...>]

John Peng wrote:
> 
> I am not sure I understand what particular problem you are trying to deal
> with.  If you used QFJ JMX agents before, esp. the quickfix/j mbean, you
> should know that QFJ does provide a nice way of managing session sequence
> online, and remotely if you will.
> 

>From FIX 4.4 spec:


> After authentication, the initiator and acceptor must synchronize their
> messages through interrogation of the MsgSeqNum field before sending any
> queued or new messages.  A comparison of the MsgSeqNum in the Logon
> message to the internally monitored next expected sequence number will
> indicate any message gaps.  Likewise, the initiator can detect gaps by
> comparing the acknowledgment Logon  message’s MsgSeqNum to the next
> expected value. The section on message recovery later in this document
> deals with message gap handling.
> ...
> When using the ResetSeqNumFlag to maintain 24 hour connectivity and
> establish a new set of sequence numbers, the process should be as follows. 
> Both sides should agree on a reset time and the party that will be the
> initiator of the process.  Note that the initiator of the ResetSeqNum
> process may be different than the initiator of the Logon process. One side
> will initiate the process by sending a TestRequest and wait for a
> Heartbeat in response to ensure of no sequence number gaps.  Once the
> Heartbeat has been received, the initiator should send a Logon with
> ResetSeqNumFlag set to Y and with MsgSeqNum of 1.  The acceptor should
> respond with a Logon with ResetSeqNumFlag set to Y and with MsgSeqNum of
> 1.  At this point new messages from either side should continue with
> MsgSeqNum of 2.  It should be noted that once the initiator sends the
> Logon with the ResetSeqNumFlag set, the acceptor must obey this request
> and the message with the last sequence number transmitted “yesterday” may
> no longer be available.  The connection should be shutdown and manual
> intervention taken if this process is initiated but not followed properly.
> 

The JMX options I'm aware of are reset() and resetSequence(int nextSeqNum). 
The former does a logout, disconnect and state reset which can achieve much
the same result but does not conform to the recommendation above which is
designed to ensure that the message delivery is in a good state prior to
resetting the sequences.  The latter simply sends a SEQUENCE_RESET message
and does no state management.

These JMX commands would only be used to jolt a failed session back into
life, not to properly manage a Sequence Number Reset on a properly working
session.


John Peng wrote:
> 
> As for the scenario that Jan desribed, it can be easily addressed by
> bundling a command to remove (or relocate if you want to keep) the
> file-store in the "start of day" start up script.  This way, the seq no.s
> are always reset at the start of each day.  For intra-day re-start
> however, you don't want to reset the seq no of course.
> 

This approach has the same problem, there is no way to be certain that the
session terminated cleanly.  There may be resends due on startup based on
the sequence numbers as known to the two sides at time of last disconnect.
-- 
View this message in context: http://n2.nabble.com/Managing-SeqNo-manually-tp2095579p2113392.html
Sent from the QuickFIX/J mailing list archive at Nabble.com.