我已经尝试处理这个问题一段时间了,我相信这可能与MsgSeqNum在客户端和服务器之间不同步有关,但是由于它开始是随机的,现在无法连接,我不再那么确定了。在
有时,在激活重置MsgSeqNum客户端的标志后,它会返回一条消息,表明服务器期望更高的MsgSeqNum并收到“1”(正如我重置了我的),但是即使我反复尝试连接以增加客户端MsgSeqNum以匹配服务器的MsgSeqNum,我也会在日志中看到同样的错误。在
在日志中,像“onCreate”这样的消息只是我添加的调试消息,用来跟踪哪些方法最终被执行。在
如果有人能提供对这个问题的见解和任何新的尝试,我将非常感激,并感谢你阅读!在
注意:我不能重置服务器的MsgSeqNum,因为您只能在登录后发送该标志,而我从来没有机会这样做。在
onCreate
<20180619-19:51:30.000000000, FIX.4.4:SENDER->TARGET, event>
(Created session)
<20180619-19:51:30.000000000, FIX.4.4:SENDER->TARGET, event>
(Connecting to BROKERADDRESS on port 8101 (Source :0))
toAdmin
<20180619-19:51:30.000000000, FIX.4.4:SENDER->TARGET, outgoing>
(8=FIX.4.4 9=112 35=A 34=52 49=SENDER 52=20180619-19:51:30.000 56=TARGET 554=PASSWORD 98=0 108=5 10=220 )
<20180619-19:51:30.000000000, FIX.4.4:SENDER->TARGET, event>
(Initiated logon request)
<20180619-19:51:31.000000000, FIX.4.4:SENDER->TARGET, incoming>
(8=FIX.4.4 9=77 35=5 34=40 49=TARGET 52=20180619-19:51:31.691 56=SENDER 10=228 )
fromAdmin
<20180619-19:51:31.000000000, FIX.4.4:SENDER->TARGET, event>
(Received logout request)
toAdmin
<20180619-19:51:31.000000000, FIX.4.4:SENDER->TARGET, outgoing>
(8=FIX.4.4 9=77 35=5 34=53 49=SENDER 52=20180619-19:51:31.000 56=TARGET 10=216 )
<20180619-19:51:31.000000000, FIX.4.4:SENDER->TARGET, event>
(Sending logout response)
<20180619-19:51:31.000000000, FIX.4.4:SENDER->TARGET, event>
(Disconnecting)
onLogout
toAdmin
您的服务器需要更高的序列号。要解决这个问题,您可以发送ResetSeqNumFlag(Tag=141),因为在此之后您的服务器也应该重置其序列号。在
您可以在应用程序中使用Quickfixj config ResetOnLogon as Y,它将在登录时自动执行此操作。在
请参考https://www.quickfixj.org/usermanual/1.6.1/usage/configuration.html
相关问题 更多 >
编程相关推荐