When the quickfix initiator reconnects at startTime
(defined in config) it deletes the files with sequence number, but does not set ResetSeqNumFlag
to Y
, and the server replies with a Logout
message with text "seq msg number to low ..."
Is there a way to set ResetSeqNumFlag = Y
only for this behavior? I don`t want to reset the sequence on every log-on.
This appears to be a QuickFIX/J quirk (some might consider it a bug). If ResetOnLogon=N then no ResetSeqNumFlag=Y is sent when the session start time triggers a logon. If ResetOnLogon=Y, the ResetSeqNumFlag=Y is sent on every logon. I believe this is not a big problem in practice because participants in a FIX session typically reset their sequence numbers locally after a session ends (logically ends at the end time, not a connection disconnect).
If you want to slightly modify the source code to implement this behavior, you'd modify the quickfix.Session next() method. You could add a local flag that indicates a session has restarted (per the schedule as determined by checkSessionTime()). Pass that flag to generateLogon() and that method would use it to determine when to send ResetSeqNumFlag=Y regardless of the ResetOnLogon configuration.
start date
and end date
as well –
Metacenter I don`t want to reset the sequence on every log-on.
Then don't do it! Set ResetOnLogon=N
.
At StartTime, the session will reset sequence numbers always. If ResetOnLogon=N
, then they won't reset again until the next StartTime.
The initiator and acceptor should always have matching ResetOnXXX
settings.
What you are asking cannot, should not be done. You start you engine with some config and then you change the config while running. If something goes wrong it will be very difficult to pinpoint what started the issue.
Instead of doing ResetSeqNumFlag = Y
try adding ResetOnLogon=Y
in your config for the acceptor side(that is if you have control over it) or ResetOnLogout=Y
/ ResetOnDisconnect=Y
in your initiator config file. That would be much easier and changing config while running, is possibly not the best solution.
Your logout(disconnect can happen anytime) will happen anyways at EndTime anyways and should be easier for your application.
© 2022 - 2024 — McMap. All rights reserved.