我正在使用QuickFix / J（FIX 4.2）将订单提交给接受者FIX引擎。基本上我需要两个帐户的帮助：
当我第一次尝试与接受者建立连接时，接受者拒绝初始登录请求，说“Msg Seq No too Low”。在此之后，我的发起者继续将输出序列号递增一，当此序号为。和没有。通过接受器引擎匹配，我获得了稳定的连接。为了加快这个过程，我开始提取预期的seq。没有。来自接受器引擎发送的拒绝消息并更改了传出序列号。我的引擎使用
session.setNextTargetMsgSeqNum(expectedSeqNo).
但是，稍后，如果我的引擎发现传入序列号。高于预期，它发送重发请求。作为响应，另一方发回序列重置消息（35 = 4,123 = Y）。现在收到这个消息后，传入的seq没有。我的引擎应自动设置为从Seq Reset msg收到的引擎。但这没有发生，我的引擎继续要求消息重发请求，而没有改变传入的seq号。 有趣的是，当我没有在第一个地方显式更改传出的seq no时（使用setNextTargetMsgSeqNum），我发现这个东西能够工作。
为什么我的引擎在获得Sequence Reset Msg？
我已与对方交谈，他们的配置中不会有ResetOnLogon = Y.所以每次我的引擎启动时，它都会发送一个seq no的Logon请求。低于预期（从1开始）。有没有更好的方法快速建立连接？就像我可以以某种方式使我的引擎使用序列号。从它倒塌前的那一点开始恢复？什么应该是理想的方法？
所以我现在将消息保存在一个处理序列号的文件中。然而，令人不安的是，我的quickfix启动器引擎没有响应序列重置消息。现在根本没有管理员回拨。
我注意到，当我从一个服务器连接到acceptor然后关闭该会话，并使用不同的服务器连接到接受器时，几乎总是没有响应序列重置消息，使用相同的会话ID。一旦登录被接受，我希望事情能够正常工作。然而，当另一个引擎将序列重置发送到特定数字（基本上是间隙填充）时，我的修复引擎不响应它，这意味着它不会重置其预期的序列号并继续向接受者发送重发请求。任何帮助将不胜感激！
答案 0 :(得分：10)
对于正常的FIX会话使用，您可以配置会话的开始和结束时间，并让引擎管理序列号。例如，如果您的会话在上午8:00到下午4:30之间处于活动状态，则QuickFIX / J将在上午8:00（或8：8）之后第一次启动引擎时自动将传出和传入序列号重置为1：如果发动机当时已经启动，则上午00点。）
（问题＃1）。您是正确的，您的引擎应在序列重置后使用新的传入序列号。鉴于这适用于成千上万的QuickFIX / J用户，请考虑一下您可能会做什么会改变这种行为。例如，您是否有管理消息回调，可能会抛出异常。您是否查看了日志文件以查看是否有任何提示？
（问题＃2）。如果您正在使用持久性MessageStore（FileStore，JdbcStore等），那么当您重新启动时，您的传出序列号将可用。