QuickfixJ出现Low msg seq错误后重置消息序列号问题咨询

• 手动调用setNextSenderMsgSeqNum和setNextTargetMsgSeqNum的时机错误：toAdmin是Admin消息发出前触发的回调，你在该回调内修改会话序列号后，既没有同步修改当前待发送Logon消息的MsgSeqNum(34)标签，也没有添加ResetSeqNumFlag(141)重置标识标签，对端会判定你的Logon消息序列号异常，不会返回响应，自然不会生成后续Logon交互日志。
• 未开启会话允许重置序列号的相关配置，默认FIX协议实现（如QuickFIX/J）会静默拦截非标准的序列号重置请求，不会执行后续登录流程。

方案1：标准协议重置流程（推荐，符合FIX规范） #

不需要手动修改会话序列号，依靠协议自带能力完成重置，兼容性最高

• 首先在会话配置文件中添加参数：ResetOnLogon=Y，如果需要登出/断连后自动重置序列号，可额外添加ResetOnLogout=Y、ResetOnDisconnect=Y
• 用户点击重置复选框发起登录时，仅需在toAdmin回调中给待发送的Logon消息添加ResetSeqNumFlag(141)=Y标签即可，无需手动调用设置序列号的方法
  参考代码：

// toAdmin回调内逻辑
if (msg instanceof Logon && 重置标识为true) {
    msg.setBoolean(ResetSeqNumFlag.FIELD, true);
}

• 协议栈会自动识别该标签，将收发序列号重置为1，同时自动修改当前Logon消息的序列号为1；对端收到带141标签的Logon消息也会同步重置自身序列号，返回响应Logon，生成完整的交互日志。

方案2：手动重置适配（仅适用于必须走自定义流程的场景） #

如果你必须通过手动调用方法修改序列号，需要调整操作顺序：

• 不要在toAdmin回调内执行序列号修改操作，应该在用户触发重置、发起登录请求前，就调用Session.lookupSession(sessionId).setNextSenderMsgSeqNum(1)和Session.lookupSession(sessionId).setNextTargetMsgSeqNum(1)
• 之后在toAdmin回调中校验Logon消息的MsgSeqNum(34)值，如果不为1则手动修改为1
• 额外补充配置：CheckLatency=N（测试环境时间差较大时开启）、AllowUnknownMsgFields=Y（如果有自定义扩展标签）

• 检查配置中FileLogPath路径是否正确，ScreenLogShowAdminMessages是否设置为Y，默认部分FIX实现不会在控制台打印Admin类消息，只会写入本地日志文件
• 确认网络连通性：如果对端未收到你的Logon消息，或者返回的响应被防火墙拦截，也不会生成后续日志，可先通过抓包确认Logon消息是否已经正常发出

内容的提问来源于stack exchange，提问作者S Shah