c++ - quickfix 会自动响应测试请求消息吗？

Question

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

当它收到来自对方的testrequest消息时，fixlog中没有心跳响应的记录，连接断开。

烦人的是，应用程序似乎进入了一个连接失败和失败的循环，直到应用程序重新启动，然后它立即重新连接。

测试请求被错误回复的可能性有哪些，或者应用程序状态重启会有所不同？

编辑

这变得更奇怪了。消息日志没有显示我在问题中描述的内容

事件日志读取

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 错误中恢复，则需要重新创建它。

Answer 1

Quickfix 自动处理测试请求/心跳消息；您可以在事件文件日志中检查测试请求断开连接的原因。可能的原因之一是您本地机器和远程对方机器上的时差。

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