彭博API请求超时

我只是想和大家分享一些东西,多亏了你在第一篇文章中包含的代码。

基本上,不要对会话对象调用NextEvent()!改用专用事件队列。

而不是这样做:

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不是特别确定的。。。

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

基于服务器API文档中的一个小的、显然是一次性的注释,我们选择创建第二个会话。一个会话负责静态请求,另一个负责实时请求。例如

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

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

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

我对这些文件的阅读同意,您需要为“//blp/mktdata”和“//blp/refdata”服务单独设置会话。

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

很高兴看到stackoverflow上的另一个人正在享受彭博API带来的痛苦:-)

  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;
    }
  }

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

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