0

我想澄清QuickFIX/J（FIX 4.2）在以下情况下的行为。QuickFIX/J此通信涉及两方：

  1. 客户端发起程序，称为I。
  2. 我们公司的接受者程序，称为A。

当我登录A时，他们用 tag 交换 FIX 消息35=A。建立连接后，我开始提交订单。然而，可能有一点，我意外断开连接，此时A决定为I的所有未结订单发送取消（这是有效的，因为A不知道我为什么失败或我什么时候会活着回来）。

请注意，整个取消连接过程由A单独启动和处理 - 它从A的onLogout(...)方法启动并由其正常的订单管理机制处理。为I35=F的每个未结订单生成一条消息，并在每次成功取消时生成一个( )。ExecutionReport35=8

当我活着回来时，这些ExecutionReports 必须以某种方式交付给我，以便它知道它之前的所有订单都已被取消。我的印象是，QuickFIX/J消息队列实现在没有应用程序级帮助的情况下处理了这个问题。确保所有QuickFIX消息都能传递给交易对手 ( http://permalink.gmane.org/gmane.comp.finance.quickfix.devel/169 )。

然而，与我的理解相反，A的日志ExecutionReport中没有显示，或者在我重新连接时没有发送给我，导致我不知道它之前的订单已被取消。我注意到由于in方法的以下源代码没有发生日志记录：QuickFIXsendRaw(Message message, int num)SessionQuickFIX/J

/**
 * Send the message
 *
 * @param message is the message to send
 * @param num is the seq num of the message to send, if 0, the next expected sender seqnum is used.
 * @return
 */
private boolean sendRaw(Message message, int num) {
    ...
        } else {
            try {
                application.toApp(message, sessionID);
            } catch (final DoNotSend e) {
                return false;
            } catch (final Throwable t) {
                logApplicationException("toApp()", t);
            }
            messageString = message.toString();
            if (isLoggedOn()) { // happens only if session is connected
                result = send(messageString); // logging happens within "send"
            }
        }
    ...
}

在为IExecutionReport断开连接发起的取消生成消息时，会话未登录，因此它从未命中并且没有发生日志记录。我相信出于同样的原因，没有消息排队（基于我没有收到任何消息的事实）。send(messageString);

我们公司基于QuickFIX/J保证所有消息都能无损传递的信念进行了许多实施，但我对上述场景的观察表明并非如此。

QuickFIX/J当会话未登录时， 的消息队列在这种情况下的表现如何？无论如何，它应该排队消息，等待将来会话再次可用时发送，还是在会话关闭时停止排队？

4

3 回答 3

1

就在private boolean sendRaw(Message message, int num)方法的最后有这段代码：

if (num == 0) {
    final int msgSeqNum = header.getInt(MsgSeqNum.FIELD);
    if (persistMessages) {
        state.set(msgSeqNum, messageString);
    }
    state.incrNextSenderMsgSeqNum();
}

如果会话未连接，将调用实际存储消息以供以后传递state.set(msgSeqNum, messageString)。messageStore.set(sequence, message)

据我所知，所有消息都将排队，直到会话成功登录。

于 2016-01-31T22:49:32.410 回答
0

这是我的 10 美分：当 QF/J 根据序列号和间隙填充保证活动会话的消息传递时......

如果会话丢失，则无法保证任何事情。一旦发现序列号不匹配，您需要做的是配置启动器和接受器以在重新连接时填充间隙。嗯，你的 ResetOnDisconnect 标志在配置中说什么？ResetOnLogout 怎么样？

我认为在 QF 中没有等待会话的消息“队列”，因为会话可以迪斯科并且永远不会侦察，这意味着 QF 队列只是不断填充，或者永远处于活动状态，这不是 QF 能够做到的为所有人开箱即用。

如果您有迪斯科舞厅，您也不能使用 OnLogout 向断开连接的客户端发送执行报告！首先，每个迪斯科舞厅并不总是调用 OnLogout，其次，正如您所说，我们进入了 QF 内部，它找不到向其发送消息的会话，因此它除外。我不希望 QF 内部队列为我处理这种情况。同样，保证交付是在连接正常时......这是一个依赖项。但是，我希望它会记录在某个地方。你的日志配置是什么？

我认为你需要看看为什么：“当 / 活着回来时，这些 ExecutionReports 必须以某种方式传递给 / ，以便它意识到它之前的所有订单都已被取消。” 这个过程不是比迪斯科舞厅的所有订单都被取消吗？为什么/需要确认？这是给定的，不是吗？这可能是您必须单独编码到 QF 基础的东西。

于 2016-01-14T12:44:54.580 回答
0

读这个。

一些公司支持消息中的标签35002（断开连接时取消）LOGON，可能的值：

  • 0：不使用 COD
  • 1：仅在发送“优雅”注销时使用 COD
  • 2：在任何“网络”断开时使用COD
  • 3：1和2

了解您的交易对手是否支持这一点。我没有检查 QuickFIX 支持，但您始终可以自己手动添加标签，或自定义您的 FIX 字典以支持该标签。

显然，这经常被高频交易者使用。我不熟悉该行业，因此评论部分中的问题。

于 2016-01-16T20:08:37.543 回答