QuickFix 序列重置不起作用

发布于 2024-12-25 15:32:49 字数 1006 浏览 3 评论 0原文

我正在使用 QuickFix/J (FIX 4.2) 将订单提交给接受方 FIX 引擎。基本上我需要两个帐户的帮助:

  1. 当我第一次尝试与接受者建立连接时,接受者拒绝初始登录请求,并说“消息序列号太低”。此后,我的发起者继续将传出序列号增加一,并且当该序列号达到时。和没有。按照接受器引擎匹配的预期,我获得了稳定的连接。为了加快这个过程,我开始提取预期的序列。不。来自接受器引擎发送的拒绝消息并更改了传出序列号。对于我的引擎使用

    session.setNextTargetMsgSeqNum(expectedSeqNo)。
    

    但是,稍后,如果我的引擎发现传入序列号。高于预期,它会发送重新发送请求。作为响应,另一方发回序列重置消息(35=4,123=Y)。现在收到此消息后,传入序列号。我的引擎应该自动设置为从 Seq Reset 消息收到的引擎。但这并没有发生,我的引擎继续要求消息重新发送请求,传入的序列号没有变化。 有趣的是,当我一开始没有显式更改传出序列号(使用 setNextTargetMsgSeqNum)时,我发现这个东西可以工作。

    为什么我的引擎在获取序列重置消息时没有显示预期行为?

  2. 我已经与对方交谈过,他们的配置中没有 ResetOnLogon=Y。因此,每次我的引擎启动时,它通常会发送带有序列号的登录请求。低于预期(从 1 开始)。有没有更好的方法可以快速建立连接?就像我可以以某种方式让我的引擎使用序列号吗?从下降之前的点恢复?理想的方法应该是什么?

因此,我现在将消息保存在一个负责处理序列号的文件中。然而,再次令人不安的是,我的 QuickFix 启动器引擎没有响应序列重置消息。现在根本没有管理员回电。

我注意到,当我从一台服务器连接到接受器,然后关闭该会话,并使用相同的会话 ID 使用不同的服务器连接到接受器时,几乎总是不会发生对序列重置消息的响应。一旦登录被接受,我希望一切顺利。然而,当另一个引擎将序列重置发送到特定数字(基本上是间隙填充)时,我的修复引擎不会响应它,这意味着它不会重置其预期序列号,并继续向接受器发送重新发送请求。任何帮助将不胜感激!

I am working on QuickFix/J (FIX 4.2)to submit orders to an acceptor FIX engine. Basically I need help on two accounts:

  1. When I first try to establish a connection with the acceptor, the acceptor rejects the initial Logon requests saying "Msg Seq No too Low". After this my initiator goes on incrementing the outgoing sequence number by one and when this seq no. and the no. expected by the acceptor engine match, I get a stable connection. To speed this process, I began to extract the expected seq. no. from the reject message sent by the acceptor engine and changed the outgoing sequence no. for my engine using

    session.setNextTargetMsgSeqNum(expectedSeqNo).
    

    However, later on, if my engine finds incoming sequence no. higher than expected, it sends a Resend request. In response, the other party sends back a Sequence Reset msg (35=4, 123=Y). Now after receiving this msg, incoming seq no. for my engine should be automatically set to the one it received from Seq Reset msg. But this does not happen and my engine goes on asking for messages resend request with no change in the incoming seq no.
    Interesting thing is, I found this thing to work when I don't explicitly change the outgoing seq no in the first place (using setNextTargetMsgSeqNum).

    Why is my engine not showing expected behavior when it gets Sequence Reset Msg?

  2. I have talked to the other party and they won't have ResetOnLogon=Y in their configuration. So every time my engine comes up, it often sends Logon request with a seq no. lower than expected(starts from 1). Is there a better way to have the connection set up quickly? Like can I somehow make my engine use the sequence no. resuming from the point just before it went down? What should be the ideal approach?

So I am now persisting the messages in a file which is taking care of sequence numbers. However, what is troubling again is, my quickfix initiator engine is not responding to Sequence Reset messages. There are no admin call backs at all now.

I notice that no response to sequence reset message is happening almost always when I am connecting to the acceptor from one server and then, closing that session, and using a different server to connect to the acceptor, using the same session id. Once the logon is accepted, I expect things to work fine. However, while the other engine sends sequence reset to a particular number (gap fill basically), my fix engine does not respond to it, meaning, it does not reset its expected sequence number and keeps on sending resend requests to the acceptor. Any help will be greatly appreciated!

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

阳光下慵懒的猫 2025-01-01 15:32:49

对于正常的 FIX 会话使用,您可以配置会话开始和结束时间,并让引擎管理序列号。例如,如果您的会话在上午 8:00 到下午 4:30 期间处于活动状态,则当引擎在上午 8:00 后(或晚上 8:00)第一次启动时,QuickFIX/J 会自动将传出和传入序列号重置为 1。上午 00 点(如果此时发动机已启动)。

(问题#1)。您的引擎应该在序列重置后使用新的传入序列号,这是正确的。鉴于这对于成千上万的 QuickFIX/J 用户来说是正常的,请考虑一下您可能会做什么来改变这种行为。例如,您是否有管理消息回调并且它可能会抛出异常。您是否查看过日志文件以查看其中是否有任何提示?

(问题#2)。如果您使用持久性 MessageStore(FileStore、JdbcStore 等),则重新启动时您的传出序列号将可用。

For normal FIX session usage, you configure the session start and end times and let the engine manage the sequence numbers. For example, if your session is active from 8:00 AM to 4:30 PM then QuickFIX/J will automatically reset the outgoing and incoming sequence number to 1 the first time the engine is started after 8:00 AM (or at 8:00 AM if the engine is already started at that time).

(Question #1). You are correct that your engine should use the new incoming sequence number after the Sequence Reset. Given that this works properly for thousands of QuickFIX/J users, think about what you might be doing that would change that behavior. For example, do you have an admin message callback and might it be throwing exceptions. Have you looked at your log files to see if there are any hints there?

(Question #2). If you are using a persistent MessageStore (FileStore, JdbcStore, etc.) then your outgoing sequence number will be available when you restart.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文