QuickFix 1.13.3- seqnum在启动时间与ODBC商店未正确重置
https://stackoverflow.com/questions/3905727
-
29-09-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russian题
我使用的是使用ODBC重新编译的QuickFix 1.13.3，并且对受体有一个奇怪的行为（不同的机器上的两个受体共享相同的ODBC数据库并启用了Hot Failover）。我的每日会议设置为：
RefreshOnLogon=Y
StartTime=00:02:00
EndTime=23:58:00
PersistMessages=Y
以及必要的ODBC设置。
在23:54，启动器将注销使用msgseqnum = 1711，我的QuickFix受体通过注销msgseqnum = 1711响应，所以那里没有问题。
在00:05:16，启动器发送了一个带有msgseqnum = 2的登录，但是我的QuickFix受体通过注销msgseqnum = 1712响应！
在00:05:18，启动器用登录和msgseqnumm = 4重试，这次，我的QuickFix受体以登录smsgseqnum = 1响应
ODBC认为，也许在“会话”中，incoming_seqnum和Out out out_seqnum也许在“会话”中，我什至尝试在00:00手动强制重置一个，但我仍然徒劳地强制重置。
我目前的猜测是，使用此配置的QuickFix仍然与昨天的会话相匹配登录请求，从而导致登录与昨天序列编号的记录。
同样 StartTime, EndTime, ，1个受体（而不是两个）， FileStore, ， 和不 RefreshOnLogon 设置（因为我只有1个受体），它曾经与QuickFix 1.12.4一起使用。
我也尝试了 RefreshOnLogon=N 但是问题仍然相同...午夜时分无法正确重置seqnums。
有任何想法吗？
非常感谢，
解决方案
经过多次尝试，我终于回滚至1.12.4使用ODBC重新编译。通过相同的设置，旧库的工作正常，并且在00:02:00正确重置了seqnums。
RefreshOnLogon=Y
StartTime=00:02:00
EndTime=23:58:00
PersistMessages=Y
其他提示
您的配置文件中是否设置了USELECALTIME？如果是这样，您应该注意到QuickFix在1.12.4之后将其损坏。我在这个错误上注意到的是2160的修订： http://sourceforge.net/tracker/?func=detail&aid=3023908&group_id = 37535＆atid = 1126912
