Question

我有一个quickfix应用程序，偶尔根据FIX日志发送testrequest消息，对方总是响应。 tag112设置等于原始消息的tag112。

当收到来自交易对手的testrequest消息时，修复日志中没有心跳响应的记录，并且连接被丢弃。

令人讨厌的是，应用程序似乎进入了一个无法连接和失败的循环，直到应用程序重新启动，当它立即重新连接时。

测试请求被错误地回复有什么可能性，或者应用程序状态是否会重新启动会产生影响？

修改

这是得到的。消息日志没有显示我在问题中描述的内容

事件日志读取

20160103-21:06:14.807 : Connecting to 127.0.0.1 on port xxxxx
20160103-21:06:14.810 : Initiated logon request
20160103-21:06:14.871 : Received logon response
20160104-00:39:34.003 : IO Error: Unable to flush file /tmp/FIX.4.4-xxxxxxxxxx.body
20160104-00:39:49.670 : IO Error: Unable to write to file /tmp/FIX.4.4-xxxxxxxxxx.body
20160104-00:40:16.671 : Socket Error: Connection reset by peer.
20160104-00:40:16.671 : Disconnecting
20160104-00:40:29.194 : Connecting to 127.0.0.1 on port xxxxx
20160104-00:40:29.195 : IO Error: Cannot seek to end of /tmp/FIX.4.4-xxxxxxxxxx.body
20160104-00:40:29.195 : Initiated logon request
20160104-00:40:39.539 : Timed out waiting for logon response
20160104-00:40:39.539 : Disconnecting
20160104-00:40:39.540 : IO Error: Unable to write to file /tmp/FIX.4.4-xxxxxxxxxx.body

此循环一直持续到应用程序重新启动。硬盘空间并不短缺，显然没有文件权限问题或重启不会有帮助 - 但由于某种原因，quickfix偶尔会无法写入自己的日志文件。

修改

到目前为止唯一的线索是日志文件中的最后一条消息与IO错误一致，达到相同的毫秒级。到目前为止，移动消息日志/ tmp似乎已经解决了 - 虽然它没有解释为什么抛出IO错误，或者为什么quickfix无法从中恢复。我猜测如果无法从IO错误中恢复，则需要重新创建messagestorefactory。

Answer 1

Quickfix自动处理testrequest / heartbeat消息; 您可以在事件文件日志中检查testrequest上断开连接的原因。可能的原因之一是本地计算机和远程交易对手的计算机上存在时差。

此外，在会话配置文件中设置ResetOnDisconnect = Y将有助于在异常终止后重新连接会话而无需重新启动应用程序。

quickfix会自动响应testrequest消息吗？

1 个答案: