Bloomberg API request timing out

Question

Having set up a ReferenceDataRequest I send it along to an 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);

Normally I can grab the message from the queue, but I'm hitting the situation now that if I'm making a number of requests in the same run of the app (normally around the tenth), I see a TIMEOUT EventType

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

These are being made on the same thread, but I'm assuming that there's something somewhere along the line that I'm consuming and not releasing.

Anyone have any clues or advice?

There aren't many references on SO to BLP's API, but hopefully we can start to rectify that situation.

Solution 1

I didn't really ever get around to solving this question, but we did find a workaround.

Based on a small, apparently throwaway, comment in the Server API documentation, we opted to create a second session. One session is responsible for static requests, the other for real-time. e.g.

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

The means one session operates in subscription mode, the other more synchronously - I think it was this duality which was at the root of our problems.

Since making that change, we've not had any problems.

Solution 2

I just wanted to share something, thanks to the code you included in your initial post.

If you make a request for historical intraday data for a long duration (which results in many events generated by Bloomberg API), do not use the pattern specified in the API documentation, as it may end up making your application very slow to retrieve all events. Basically, do not call NextEvent() on a Session object! Use a dedicated EventQueue instead.

Instead of doing this:

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

Do this:

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

This can result in some performance improvement, though the API is known to not be particularly deterministic...

Solution 3

My reading of the docs agrees that you need separate sessions for the "//blp/mktdata" and "//blp/refdata" services.

Solution 4

A client appeared to have a similar problem. I solved it by making hundreds of sessions rather than passing in hundreds of requests in one session. Bloomberg may not be to happy with this BFI (brute force and ignorance) approach as we are sending the field requests for each session but it works.

View more solutions

Comments

[Unsliced]

Thanks. That's a very similar construction (and does like like the example code) - there are no unconsumed messages that I can see in previous calls through this function. If I call it just once, it's fine, but it's barfing after multiple calls. I think it might be related to a concurrent subscription to some RealTime fields, but it's quite hard to nail down ...

[Nick Fortescue]

are you sharing the same queue between ref-data and market-data? That might be a problem.

[Jamal Ashraf]

I think the issue is that you're now explicitly opening the service before you get the reference. We use if (session.OpenService(BlpConstants.BLP_REF_DATA)) return session.GetService(BlpConstants.BLP_REF_DATA); else return null; whereas your initial question did not open the service first