6

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

通常、キューからメッセージを取得できますが、アプリの同じ実行（通常は10分の1）で多数のリクエストを行うと、TIMEOUTEventTypeが表示されるという状況に陥っています。

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

これらは同じスレッドで作成されていますが、私が消費していてリリースしていないものがどこかにあると思います。

誰か手がかりやアドバイスはありますか？

SOに関するBLPのAPIへの参照は多くありませんが、うまくいけば、その状況を修正し始めることができます。

4

7 に答える 7

5

最初の投稿に含めたコードのおかげで、何かを共有したかっただけです。

日中の履歴データを長期間要求する場合（ブルームバーグ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は特に決定論的ではないことが知られていますが、これによりパフォーマンスがいくらか向上する可能性があります...

于 2011-05-25T15:48:19.543 に答える
4

私はこの質問を実際に解決することはできませんでしたが、回避策を見つけました。

サーバーAPIドキュメントの小さな、明らかに使い捨てのコメントに基づいて、2番目のセッションを作成することを選択しました。1つのセッションは静的リクエストを担当し、もう1つのセッションはリアルタイムを担当します。例えば

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

つまり、一方のセッションがサブスクリプションモードで動作し、もう一方のセッションがより同期的に動作するということです。問題の根本にあったのは、この二重性だったと思います。

その変更を行って以来、問題は発生していません。

于 2009-11-24T14:57:37.087 に答える
1

ドキュメントを読んだところ、「// blp/mktdata」サービスと「//blp/refdata」サービスに別々のセッションが必要であることに同意しています。

于 2009-12-02T14:02:41.270 に答える
1

クライアントにも同様の問題があるようです。1回のセッションで数百のリクエストを渡すのではなく、数百のセッションを作成することで解決しました。ブルームバーグは、セッションごとにフィールドリクエストを送信しているため、このBFI（ブルートフォースアンドイグノセンス）アプローチに満足していない可能性がありますが、機能します。

于 2010-08-01T00:28:27.390 に答える
0

スタックオーバーフローで別の人がブルームバーグ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;
    }
  }

これは、各イベントからすべてのメッセージを消費するため、機能する可能性があります。

于 2009-09-18T10:06:47.143 に答える
-1

ちなみに、サンプルコードからはわかりませんが、イベントキューからのメッセージでブロックされている間、（別のイベントキューにある）メインイベントキューからも読み取っていますか？特に未処理のサブスクリプションがある場合は、キューからすべてのメッセージを処理する必要があります。応答は非常に速くキューに入れられます。メッセージを処理していない場合、セッションがキューの制限に達する可能性があります。これが、タイムアウトが発生する理由である可能性があります。また、メッセージを読まないと、遅いコンシューマーとしてマークされ、保留中のメッセージの消費を開始するまでそれ以上のデータを受信しない可能性があります。APIは非同期です。イベントキューは、ブロックに問題がない状況でメインキューからのすべてのメッセージを処理することなく、特定のリクエストをブロックする方法にすぎません。

于 2009-12-15T14:01:19.067 に答える
-1

一度にリクエストが多すぎるようです。BBは、常に接続ごとに特定の数の要求のみを処理します。サブスクリプションごとにも制限があるため、接続を増やすことは役に立たないことに注意してください。時間のかかるリクエストを同時に大量に行うと、一部がタイムアウトする場合があります。また、リクエストを完全に処理するか（RESPONSEメッセージを受信するまで）、キャンセルする必要があります。未解決の部分的なリクエストは、スロットを浪費しています。2つのセッションに分割することはあなたを助けたようですので、あなたは同時にたくさんのサブスクリプションリクエストをしているようです。スナップショットを撮る方法としてサブスクリプションを使用していますか？つまり、機器をサブスクライブし、初期値を取得して、サブスクライブを解除します。もしそうなら、あなたは別のデザインを見つけることを試みるべきです。これは、サブスクリプションの使用を目的とした方法ではありません。未処理のサブスクリプションリクエストもリクエストスロットを使用します。そのため、個別のリクエストを多数作成するのではなく、1つのサブスクリプションリストにできるだけ多くのサブスクリプションをまとめるのが最適です。これがAPIの使用に役立つことを願っています。

于 2009-12-13T22:27:51.213 に答える