Process ADMIN events in BloombergEventHandler and log appropriately

[jonfreedman]

In order to ensure that your application is processing event messages fast enough and not losing data, you will want to handle all "ADMIN" event messages. We demonstrate how to handle this event type in the "SubscriptionWithEventHandlerExample" SDK example.

If your application is not reading/processing the incoming events fast enough, the internal queue of the API library will begin queuing up all event messages. When this occurs, you will receive an event of EventType ADMIN containing a message of type SlowConsumerWarning. This message will be sent once the number of undelivered events sent to the user(s) reaches the high percentage threshold set with the SessionOptions.SlowConsumerWarningHiWaterMark property (default: 0.75). This percentage is based on the maximum event queue size, which is set with the SessionOptions.MaxEventQueueSize property (default: 10000). At this point, no data has been lost, but you are in danger of doing so if appropriate action isn't taken. Ideally, this action would be to optimize your processing of event messages or reducing your data requests/subscriptions. but you could also try increasing the maximum event size by setting the MaxEventQueueSize property value.

If you receive a SlowConsumerWarningCleared message, then you have dropped below the low percentage threshold, which is set using the SessionOptions.SlowConsumerWarningLoWaterMark (default: 0.5).

If the number of events outstanding for delivery exceeds the specified threshold controlled by SessionOptions.MaxEventQueueSize, then the Bloomberg communication server (i.e. bbcomm, serverapi, etc.) will begin dropping events, as the API library's internal queue will be full and no longer able to receive any further messages until the situation is addressed. This will be indicated by a "DataLoss" message contained in an ADMIN event.

Within this message, you will find an "id", "source" and "numMessagesDropped" property value. The "id" property identifies the affected subscription, while the "source" will have a value of "InProc", which means that it occurred within your application (currently, this is the only possible source). The final property is "numMessagesDropped", which indicates the total number of messages dropped at the time the dataloss message was received for that particular subscription. It is important to note that the subscription, identified by "id", will not be automatically canceled by the API library.

IMPORTANT NOTES:

The above information only applies to API library versions 3.5.2.1, and greater. If you are using earlier versions of the API libraries, it is advised that you upgrade in order to ensure you are using the latest supported versions and taking advantage of new features and bug fixes. In earlier C++ API library versions, for example, you will not receive any DataLoss or SlowConsumerWarning/SlowConsumerWarningCleared Admin event messages, while for earlier Java and .NET API libraries, only SlowConsumerWarning/SlowConsumerWarningCleared Admin messages will be returned, but no DataLoss Admin messages.

[assylias]

Hi, I can't find the document where you found that info, which doc is it?

At the moment, admin messages are logged with a DEBUG level. What would you want to see instead?

[jonfreedman]

The source of that quote is from Bloomberg, I am not sure whether it's actually official documentation...
I made some changes in my fork to log the SlowConsumerWarning as error, the Cleared message as info and I pass the DataLoss error back to the subscriber to process (the Bloomberg example reconnects).

I will ask again if it's possible for me to contribute from the office