tags:

views:

154

answers:

2

I made a program in c# based on the example "SubscriptionWithEventHandlerExample" of API 3.2.9.0. After subscribing to about 500 securities for realtime data, I receive some ADMIN event warnings claiming SlowConsumerWarning and SlowConsumerWarningCleared. I read somewhere that it introduces some delay, until I process all events.

The problem is that in my code I only receive callbacks from bloomberg. The event queue isn´t even in my program!

Some things that I tried:

1) raise the queue limit, setting MaxEventQueueSize in the session options (seems to have no effect)

2) see if I get any timeout event (no, I don't get any)

3) create multiple sessions and subscribing 50 securities in each (now I get multiple warnings, one for each thread)

Is there something that I can do or this behavior is out of my scope?

+3  A: 

You could do the processing of the data in a dedicated thread and only let the Bloomberg callbacks queue the data. Your data processing thread would read the data from the queue and do any time consuming work. That might solve your problem, depending on what triggers a SlowConsumerWarning. If your code to process the data is too slow, though, your queue would fill up over time.

Peter
Yes, unless you have some way of batch processing the events which is faster than one-by-one, this only moves the problem one step further down.
Jon
It may also be that the data comes in "showers" and that the queueing strategy can even out the processing over time. According to Jon's answer, though, it seems as though there might already be similar mechanism built-in into the Bloomberg API. If so, implementing it yourself might remove the warning, but do nothing to avoid the root of the problem.
Peter
+1  A: 

The Bloomberg API and associated processes are internally multi-threaded. If you subscribe to a real-time source and don't process the events fast enough so that the events internally start backing up in the Bloomberg API, the API will issue the slow consumer warning. I think at this stage it may also start throttling or dropping events. Are you doing something time-consuming in the event callback (writing to a database)?

The bottom line is that if you subscribe to real-time data for 500 securities events, your event processing has to keep up with the flow of data you've subscribed to.

Jon