The QFJ engine associate with the acceptor handle the recovery scenario
you mentioned not the Synapse initiator. This is correct and that is
the correct way FIX should recover by resetting the seq numbers of both
endpoints. In the specific case that I saw while the started QFJ engine
trying to reset the seq number and reconnect, Synapse initiator did
start another instance of QFJ engine and try to establish a new session.
I will try to recreate the issue and send the exact sequence of events.
Hiranya Jayathilaka (JIRA) wrote:
[
https://issues.apache.org/jira/browse/SYNAPSE-381?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hiranya Jayathilaka updated SYNAPSE-381:
----------------------------------------
Attachment: syn-to-exec
I still don't see any issue. I tried restarting Synapse after clearing the
message store. Then the next message Synapse sends to the acceptor will contain
the seq number 1 (ie the sequence has reset). But the acceptor expects a
message with a higher seq number. The FIX spec clearly mentions how to handle
this kind of situations:
"If the incoming message has a sequence number less than expected and the
PossDup
flag is not set it indicates a serious error and it is strongly recommended
that the session be
terminated and manual intervention be initiated."
This is exactly what the acceptor does by immediately disconnecting the
session. But Synapse initiator will keep on trying to connect to the session by
increasing the seq number at each attempt. If you wait enough you will see that
Synapse will finally manage to connect to the session.
See the attached log file from the acceptor for more details. See the inline
comments to
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
