QuickFIX/J 2.3.1：Initiator无法获取历史消息求助

使用QuickFIX/J 2.3.1版本时，Initiator无法获取历史消息，仅能接收最新消息。具体表现为：Acceptor已发送编号1至11的消息，但启动Initiator后，仅能接收到9、10、11，缺失1至8的消息。

Acceptor配置 #

# default settings for sessions
[DEFAULT]
ConnectionType=acceptor
ReconnectInterval=15
SenderCompID=QUICKFIX_ACCEPTOR
TimeZone=Asia/Shanghai
MaxLatency=3600
# log
FileStorePath=quickfixj/acceptor/store
FileLogPath=quickfixj/acceptor/log

SocketAcceptAddress=127.0.0.1
SocketAcceptPort=9823
# session definition
[SESSION]
# inherit ConnectionType, ReconnectInterval and SenderCompID from default
BeginString=FIXT.1.1
TargetCompID=INITIATOR_TEST
StartTime=00:00:00
EndTime=00:00:00
HeartBtInt=180

DataDictionary=FIX50SP2.modified.xml
UseDataDictionary=N
DefaultApplVerID=FIX.5.0SP2

[DEFAULT]
SocketReuseAddress=Y
ResetOnLogon=N
ResetOnLogout=N
ResetOnDisconnect=N
ResetOnError=N
DisconnectOnError=N
ContinueInitializationOnError=N

Initiator配置 #

# default settings for sessions
[DEFAULT]
ConnectionType=initiator
ReconnectInterval=15
SenderCompID=INITIATOR_TEST
TimeZone=Asia/Shanghai
MaxLatency=3600
# log
FileStorePath=quickfixj/initiator/store
FileLogPath=quickfixj/initiator/log
FileLogPath=quickfixj/initiator/log


# session definition
[SESSION]
# inherit ConnectionType, ReconnectInterval and SenderCompID from default
BeginString=FIXT.1.1
TargetCompID=QUICKFIX_ACCEPTOR
StartTime=00:00:00
EndTime=00:00:00
HeartBtInt=180
SocketConnectPort=9823
SocketConnectHost=127.0.0.1
DataDictionary=FIX50SP2.modified.xml
UseDataDictionary=N
DefaultApplVerID=FIX.5.0SP2

[DEFAULT]
SocketReuseAddress=Y
ResetOnLogon=N
ResetOnLogout=N
ResetOnDisconnect=N
ResetOnError=N
DisconnectOnError=N
ContinueInitializationOnError=N

问题原因与解决方案 #

核心原因

1. 序列号同步偏差：Initiator首次启动时，本地存储的初始序列号可能默认从较高值开始，导致Acceptor判定1-8号消息已被确认，无需重传。
2. 重传机制未触发：当前配置ResetOnLogon=N，未强制登录时重置序列号，也未主动发起重传请求，Acceptor不会主动推送历史未确认消息。
3. 存储文件异常：Acceptor侧的消息存储目录（quickfixj/acceptor/store）可能存在权限不足、空间不够或文件损坏，导致历史消息未被留存。

解决步骤

1. 临时重置序列号（测试环境）
   将Initiator配置中的ResetOnLogon=Y，强制登录时把本地序列号重置为1，触发Acceptor重传所有未确认的历史消息。测试完成后改回N，避免生产环境消息重复处理。

2. 主动发起重传请求（生产推荐）
   在Initiator的Application实现类中重写onLogon方法，主动发送ResendRequest指定重传范围：

   @Override
   public void onLogon(SessionID sessionID) {
       try {
           Session session = Session.lookupSession(sessionID);
           if (session != null) {
               // 请求重传从1到最新序列号的所有消息（0代表最新）
               session.sendResendRequest(1, 0);
           }
       } catch (Exception e) {
           // 处理异常逻辑
           e.printStackTrace();
       }
   }
   

3. 清理存储文件重新同步

   • 停止Acceptor和Initiator服务
   • 删除双方FileStorePath目录下的所有会话存储文件
   • 重启Acceptor并重新发送所有消息
   • 启动Initiator，此时可接收完整消息序列

4. 检查存储目录配置
   确认Acceptor和Initiator的FileStorePath目录具备读写权限，且磁盘空间充足，避免因存储失败导致历史消息丢失。

注意事项

• 生产环境使用ResetOnLogon=Y需配合业务端的幂等性校验，防止重复消息引发业务异常。
• 全量重传会增加会话负载，可根据业务需求调整重传的消息范围，避免不必要的资源消耗。

内容的提问来源于stack exchange，提问作者王勤奋