彭博 API 请求超时答案

【问题标题】：Bloomberg API request timing out彭博 API 请求超时
【发布时间】：2010-11-29 10:19:42
【问题描述】：

设置 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);

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

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

这些是在同一个线程上制作的，但我假设我正在消费而不是释放某些东西。

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

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

【问题讨论】：

标签： c# bloomberg eventqueue blpapi

【解决方案1】：

很高兴看到另一个人在 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;
    }
  }

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

【讨论】：

谢谢。这是一个非常相似的结构（并且确实喜欢示例代码） - 在之前通过此函数的调用中我可以看到没有未使用的消息。如果我只调用一次，那很好，但在多次调用后它会呕吐。我认为这可能与同时订阅某些 RealTime 字段有关，但很难确定...
您是否在 ref-data 和 market-data 之间共享同一个队列？这可能是个问题。

【解决方案2】：

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

基于服务器 API 文档中的一个小而明显的一次性评论，我们选择创建第二个会话。一个会话负责静态请求，另一个负责实时请求。例如

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

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

自从做出改变以来，我们没有遇到任何问题。

【讨论】：

我认为问题在于您现在在获得参考之前明确地打开了服务。我们使用if (session.OpenService(BlpConstants.BLP_REF_DATA)) return session.GetService(BlpConstants.BLP_REF_DATA); else return null;，而您最初的问题没有先打开服务

【解决方案3】：

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

【讨论】：

【解决方案4】：

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

【讨论】：

【解决方案5】：

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

【讨论】：

【解决方案6】：

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

【讨论】：

【解决方案7】：

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

如果您长时间请求历史盘中数据（这会导致 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 不是特别确定性...

【讨论】：