问题标签 [camel-quickfix]

我有一个非常奇怪的问题，同时以稍微不同的方式运行我的应用程序。当我在 IDE 中启动应用程序（这是一个带有骆驼的经典控制台应用程序）时，它会加载 176 个类型转换器（正如我从日志中看到的那样）。当我尝试通过 启动它时java -jar，它会加载 172 个类型转换器，并且在尝试启动路由时出现以下错误：

原因：java.lang.IllegalArgumentException：找不到合适的属性设置器：sessionID，因为没有具有相同类型的设置器方法：java.lang .String 也没有类型转换：没有可用于从类型转换的类型转换器： java.lang.String 到所需类型：quickfix.SessionID，值为BLAH

显然，它找不到camel-quickfix 模块的转换器。所有的罐子都经过仔细检查，missing jar不太可能是原因。你有什么想法 - 我如何检查正在加载的转换器列表以及如何解决这个问题？

我正在尝试从文件系统读取 cfg 文件，但找不到任何示例。是否可以创建这样的路由：Reading the config file from application.properties（这是一个弹簧启动应用程序）

应用程序属性：

提前致谢。

我们与经纪人有一个单独的会议。我们正在获取该时段的市场数据。基本上，我们只想将这些数据分发给 FIX 上的不同团队。是否有任何现成的解决方案既可以作为接受者又可以作为初始者。

Initator 将从 Broker 获取消息并将这些消息传递给接受者，而接受者将这些消息传递给它的客户端。

我们为此使用 apache camel quickfixj。

我们目前正在研究 FIX 连接，从而可以标记仅应验证的数据。已决定使用特定的TargetSubID标记此数据。但这意味着一个新的会话。

假设我们将消息发送到会话FIX.4.4:S->T。如果我们随后收到一条只应使用 TargetSubID V 验证的消息，则这意味着会话FIX.4.4:S->T/V。如果未配置此会话，我们会收到错误消息

如果我们在另一个旁边显式配置此会话，则会出现错误

正如bhageera 所说，您使用相同的凭据登录。

（...）我连接的交易对手一次只允许每个用户/密码（即使用这些凭据的会话）进行 1 个连接。

我不是 FIX 专家，但我想知道 TargetSubID 是否在这里被滥用。如果没有，我想知道该怎么做。我们使用 camel-quickfix 开发 FIX 客户端。

根据我的另一个问题，我想在发送时忽略TargetSubID 。可以使用以下配置：

而如果源系统发送一个TargetSubID “Sub”，则会出现以下错误：

是否可以告诉 QuickFix 它应该使用 FIX.4.4:Sender->Target 配置并发送TargetSubID？

我在Apache Camel 2.17.0 中使用QuickFIX/J版本 1.6.4并收到会话消息。这不是错误，但在我的情况下，它会导致意外Logoff。Disconnecting: Encountered END_OF_STREAM

什么情况会导致此消息，我如何分析我的情况是哪种情况导致的？

我在camel-quickfix 组件中使用QuickFix/J 1.6.4 。有时，我得到了CannotSendException并且不清楚异常原因是什么。我查看了代码，但似乎在无法发送消息时抛出了这个异常——不管是什么原因。

那么我该如何处理这个异常呢？我是否必须实现重试机制，或者引擎是否会为我处理这个？如果引擎有，我如何验证消息是在之后发送的？

异常堆栈跟踪（我用 *** 替换了 FIX 消息，因为我无法发布它）：

我在camel-quickfix组件中使用QuickFix/J 1.6.4 。我希望有以下会议时间表：周一至周五早上 6 点至晚上 8 点的每日会议。因此，会议应从周一早上 6 点开始，到周一晚上 8 点结束，并且在所有工作日都如此。周六和周日不会有任何会话登录。

对于那个真正常见的用例，我是否错过了一个简单的配置？我已经看到了一些与 cron 作业等有关的解决方法，但是有没有更优雅的方法？

我还尝试在每个工作日使用 quickfix 配置并检查要使用哪个配置，但我最终遇到了CannotSendException并且我认为该会话的实例存在冲突。

我们已经建立了一个修复客户端。修复客户端可以接收传入消息，但在发送最后一个心跳后无法发送传出心跳消息或回复 TestRequest 消息，触发某些东西以停止从客户端发送心跳。

修复版本：fix5.0

之前也发生过同样的事件，我们当时有一个会话的 tcpdump

我们将每个修复会话部署到单独的 k8s pod。

1. 我们怀疑这是 CPU 资源问题，因为在发布时间前后平均负载很高，但是在我们添加更多 cpu 内核后仍未解决。我们认为由于修复重新连接，平均负载很高。
2. 我们怀疑这是 IO 问题，因为我们使用由 3 个会话共享的 AWS efs 进行日志记录和消息存储。但是在我们使用 pod affinity 将 3 个 session 分配给不同的节点后仍然没有解决。
3. 这也不是网络问题，因为我们可以收到修复消息，当时其他会话运行良好。我们也在 k8s 集群中禁用了SNAT 。

我们正在使用 quickfixj 2.2.0 创建一个修复客户端，我们有 3 个会话，它们部署到不同节点中的 k8s pod。

1. 评价会话以从服务器获取外汇价格
2. 命令会话从服务器获取事务（执行报告）消息，我们只向服务器发送登录/心跳/注销消息。
3. 后台会话以获取市场状态

我们使用 apache camel quickfixj 组件来简化我们的编程。它在大多数情况下运行良好，但在 3 个会话中不断发生重新连接以修复服务器，频率就像一个月一次，大多数只有 2 个会话有问题。

heartbeatInt = 30s

客户端的修复事件消息

在客户端修复传入消息

在客户端修复传出消息

收到来自服务器的 TEST 消息时的线程转储。顺便说一句，要点来自我们具有相同部署的开发环境。 https://gist.github.com/hitxiang/345c8f699b4ad1271749e00b7517bef6

我们在 quickfixj 启用了调试日志，但信息不多，只有收到消息的日志。

我们通过 apache camel 在我们的系统中使用 quickfixj：

我们现在正在尝试解决 FIX 通道的问题，并希望了解消息通信的延迟在哪里——在我们的网络中发送消息时或在银行端。

quickfixj 有一个传出消息日志记录，但问题是日志记录完成before发送消息，然后消息本身异步发送

那么有没有什么方法可以在消息发送后才创建一些日志？通过这种方式，我们将了解在第一个日志和实际发送消息之间是否真的存在一些延迟，以及发送需要多长时间。

谢谢。

UPD：根据 Christoph 的回答，尝试以下方法：