【问题标题】:QuickFIXJ 2.3 - onDisconnect(), onConnect()QuickFIXJ 2.3 - onDisconnect(), onConnect()
【发布时间】:2021-10-06 18:30:01
【问题描述】:

我正在使用 Quickfixj 2.3 作为启动器。供应方是接受方。

我已经使用 onConnectException 和 OnDisconnect 方法实现了 SessionStateListener。

我在配置文件中有resetOnLogon =Y。

  1. 由于会话数据错误或由于接受者一次只允许一个会话或由于无效的 Msg seq,我如何捕获特定异常,例如 EndOfStream 发生?

  2. 现在,当 resetOnLogOn=Y 时,直到 msgSeq 满足,它在内部保持断开和启动。我想在所有其他断开连接时手动注销,除了自动匹配序列号的这种情况。

谢谢。

【问题讨论】:

    标签: quickfixj


    【解决方案1】:

    实际上,大多数时候你无法区分第 1 点中列出的场景。

    例如交易对手通常不会告诉您您是否有错误的会话数据(我假设您的意思是错误的SenderCompIDTargetCompID),因为这会泄露有关他们系统的信息。重复会话也是如此。

    仅在“序列号太低”事件的情况下,交易对手通常会在Logout 消息的58/Text 字段中发送此信息。

    【讨论】:

    • 第 1 点好的。第 2 点的注销原因来自 fromAdmin 方法,但是,在 resetOnLogon 、 refreshOnLogon 时,它将保持断开连接(触发内部注销)再次启动登录,直到条件匹配。所以在这种情况下,断开连接我不想注销。现在第二种情况,当连接已经启动时,第二次尝试将使 endofstreamencounterd,然后我想注销。但由于方法签名为空,我无法在断开连接时捕获此消息。
    • 当对方在登录时没有重置其序列号时,我强烈建议不要执行 resetOnLogon,这将导致您看到的序列不匹配。
    • 此外,我不知道您所说的“自动匹配序列号”是什么意思。要么太高,就会自动同步。或者太低,连接会被注销。
    猜你喜欢
    • 2021-01-21
    • 2020-11-14
    • 2018-02-28
    • 1970-01-01
    • 2015-01-09
    • 1970-01-01
    • 2020-11-27
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多