Bloomberg API 请求超时

Question

设置了 ReferenceDataRequest 后，我​​将其发送到 EventQueue

Service refdata = _session.GetService("//blp/refdata");
Request request = refdata.CreateRequest("ReferenceDataRequest");
// append the appropriate symbol and field data to the request
EventQueue eventQueue = new EventQueue();
Guid guid = Guid.NewGuid();
CorrelationID id = new CorrelationID(guid);
_session.SendRequest(request, eventQueue, id);
long _eventWaitTimeout = 60000;
myEvent = eventQueue.NextEvent(_eventWaitTimeout);

通常我可以从队列中获取消息，但现在我遇到的情况是，如果我在应用程序的同一运行中发出多个请求（通常大约第十个），我看到一个 TIMEOUT EventType

if (myEvent.Type == Event.EventType.TIMEOUT)
    throw new Exception("Timed Out - need to rethink this strategy");
else
    msg = myEvent.GetMessages().First();

这些是在同一个线程上进行的，但我假设沿线的某个地方有一些东西我正在消耗而不是释放。

有人有任何线索或建议吗？

关于 BLP API 的 SO 参考并不多，但希望我们可以开始纠正这种情况。

Answer 1

我只是想分享一些东西，感谢您在最初的帖子中包含的代码。

如果您长时间请求历史盘中数据（这会导致 Bloomberg API 生成许多事件），请不要使用 API 文档中指定的模式，因为它最终可能会使您的应用程序检索所有事件的速度非常慢。
基本上，不要在 Session 对象上调用 NextEvent()！请改用专用的 EventQueue。

不要这样做：

var cID = new CorrelationID(1);
session.SendRequest(request, cID);
do {
   Event eventObj = session.NextEvent();
   ...
}

这样做：

var cID = new CorrelationID(1);
var eventQueue = new EventQueue();
session.SendRequest(request, eventQueue, cID);
do {
   Event eventObj = eventQueue.NextEvent();
   ...
}

这可以带来一些性能改进，尽管众所周知 API 不是特别确定......

Answer 2

我并没有真正抽出时间来解决这个问题，但我们确实找到了解决方法。

根据服务器 API 文档中的一条看似一次性的小评论，我们选择创建第二个会话。一个会话负责静态请求，另一个会话负责实时请求。例如，

_marketDataSession.OpenService("//blp/mktdata"); 
_staticSession.OpenService("//blp/refdata");

这意味着一个会话以订阅模式运行，另一个会话则更加同步 - 我认为正是这种二元性才是我们问题的根源。

自从进行更改以来，我们没有遇到任何问题。

Answer 3

我对文档的阅读同意您需要为“//blp/mktdata”和“//blp/refdata”服务单独的会话。

Answer 4

一位客户似乎也遇到了类似的问题。我通过创建数百个会话而不是在一个会话中传递数百个请求来解决这个问题。彭博社可能对这种 BFI（暴力和无知）方法不满意，因为我们正在为每次会议发送现场请求，但它确实有效。

Answer 5

很高兴看到 stackoverflow 上的另一个人享受着 Bloomberg API 的痛苦:-)

我很惭愧地说我使用了以下模式（我怀疑是从示例代码中复制的）。它似乎工作得相当稳健，但可能忽略了一些重要的消息。但我不明白你的超时问题。它是 Java，但所有语言的工作原理基本相同。

  cid = session.sendRequest(request, null);
  while (true) {
    Event event = session.nextEvent();
    MessageIterator msgIter = event.messageIterator();
    while (msgIter.hasNext()) {
      Message msg = msgIter.next();
      if (msg.correlationID() == cid) {
        processMessage(msg, fieldStrings, result);
      }
    }
    if (event.eventType() == Event.EventType.RESPONSE) {
      break;
    }
  }

这可能有效，因为它会消耗每个事件的所有消息。

Answer 6

听起来您一次提出了太多请求。 BB 在任何给定时间只会处理每个连接一定数量的请求。请注意，打开越来越多的连接不会有帮助，因为每个订阅也有限制。如果您同时发出大量耗时的请求，有些请求可能会超时。另外，您应该完全处理请求（直到收到 RESPONSE 消息），或者取消它们。未完成的部分请求会浪费一个槽。由于分成两个会话，似乎对您有所帮助，听起来您也在同时发出大量订阅请求。您是否使用订阅作为拍摄快照的方式？即订阅一个工具，获取初始值，然后取消订阅。如果是这样，您应该尝试寻找不同的设计。这不是订阅的预期使用方式。未完成的订阅请求也使用请求槽。这就是为什么最好在单个订阅列表中批量处理尽可能多的订阅，而不是发出许多单独的请求。希望这对您使用 api 有所帮助。

Answer 7

顺便说一句，我无法从您的示例代码中看出，但是当您被事件队列中的消息阻止时，您是否也在（在单独的事件队列中）读取主事件队列？您必须处理队列外的所有消息，特别是当您有未完成的订阅时。响应可以很快排队。如果您不处理消息，会话可能会达到某些队列限制，这可能就是您超时的原因。此外，如果您不读取消息，您可能会被标记为慢速消费者，并且在开始消费待处理消息之前不会收到更多数据。 api 是异步的。事件队列只是一种阻塞特定请求的方法，而不必在可以阻塞的上下文中处理来自主队列的所有消息，否则很难中断逻辑流以异步处理部分。