Best practices for OmmConsumerClient#onStatusMsg(StatusMsg, OmmConsumerEvent) error handling

dgoloughlin

What are the recommended best practices for handling errors received via the OmmConsumerClient::onStatusMsg(StatusMsg, OmmConsumerEvent) callback?

On Saturday morning, a number of our subscriptions received status messages indicating Closed / Suspect / Not Entitled / Reverify. These messages were delivered via onStatusMsg. Based on this, our application logic interpreted the state as DOWN.

However, shortly afterwards we continued to receive data for the same subscriptions via onUpdateMsg(UpdateMsg, OmmConsumerEvent). As a result, the application transitioned back to UP (our assumption being that if updates are flowing, the application is effectively up).

This has raised a few questions about the correct handling strategy:

Should we resubscribe to the affected symbols when receiving these status messages?

Should we log off and re-establish the session?

Or should onStatusMsg be treated as advisory, with application health primarily determined by the presence or absence of updates?

Any guidance on the intention of these status messages and recommended handling would be great.

Jirapongse

@dgoloughlin

Thank you for reaching out to us.

A status message is used to indicate a status of a subscribed item or stream. This could be a login stream or item stream. I assume that this is for an item stream.

Typically, a status message contains the following state information.

• Stream State: e.g. Open, Closed
• Data State: e.g. Okay, Suspect
• Status Code: e.g. None, NOT_ENTITLED, NOT_FOUND
• Status Text

The state information is also available in a refresh message.

The stream state conveys data about the stream’s health. The Closed stream state indicates that data is not available on this service and connection and is not likely to become available, though the data might be available on another service or connection. Therefore, an application will not retrieve any data from this closed stream.

There is no best practice to handle the closed streams because it depends on the application's requirements.

The only way to recover closed streams is by resubscribing. In this case, the application may attempt to resubscribe to items when the stream state is closed and the status code indicates NOT_ENTITLED. However, the application will continue resubscribing until the permission issue is resolved.

Should we resubscribe to the affected symbols when receiving these status messages?

It depends on the nature of the issue and whether the problem has been resolved.

Should we log off and re-establish the session?

No. In this case, resolving the permission issue and resubscribing to the items should suffice.

Or should onStatusMsg be treated as advisory, with application health primarily determined by the presence or absence of updates?

The stream health should be determined by the stream state in the refresh or status message.