1

我正在使用用 ODBC 重新编译的 quickfix 1.13.3，我的接受器有一个奇怪的行为（不同机器上的两个接受器共享相同的 ODBC 数据库并启用了热故障转移）。我的日常会话设置为：

RefreshOnLogon=Y
StartTime=00:02:00
EndTime=23:58:00
PersistMessages=Y

和必要的 Odbc 设置。

在 23:54，发起者发送了一个带有 MsgSeqNum = 1711 的 Logout，我的 quickfix 接受器以 Logout MsgSeqNum = 1711 响应，所以没有问题。

在 00:05:16，发起者发送了一个带有 MsgSeqNum = 2 的 Logon，但我的 quickfix 接受者以 Logout MsgSeqNum = 1712 响应！

在 00:05:18，发起者使用 Logon 和 MsgSeqNum = 4 重试，这一次，我的 quickfix 接受器以 Logon MsgSeqNum = 1 响应

考虑到也许，在“会话”表中，incoming_seqnum 和传出_seqnum 没有被 ODBC 正确重置，我什至尝试在 00:00 手动强制重置，但徒劳无功，我仍然得到相同的行为。

我目前的猜测是，使用此配置的 quickfix 仍然与昨天会话的登录请求相匹配，从而导致使用昨天的序列号注销....

使用相同的StartTime, EndTime, 1 个接受器（而不是两个）,FileStore和没有RefreshOnLogon设置（因为我只有 1 个接受器），它曾经与 quickfix 1.12.4 一起使用。

我也尝试过，RefreshOnLogon=N但问题仍然存在...... seqnums 在午夜没有正确重置。

有任何想法吗？

非常感谢，

4

2 回答 2

1

经过多次不同设置的尝试，我终于回滚到使用 ODBC 重新编译的 1.12.4。使用相同的设置，旧库可以正常工作，并且 seqnums 在 00:02:00 正确重置。

RefreshOnLogon=Y
StartTime=00:02:00
EndTime=23:58:00
PersistMessages=Y
于 2010-10-15T12:58:34.060 回答
-1

你的配置文件中设置了 UseLocalTime 吗？如果是这样，您应该注意 QuickFIX 在 1.12.4 之后破坏了它。破坏它的修订版是 2160，正如我在此错误上所指出的：http: //sourceforge.net/tracker/ ?func=detail&aid=3023908&group_id=37535&atid=1126912

于 2010-11-15T02:24:24.793 回答