question

Upvotes
Accepted
11 4 4 5

When does a handle returned by thomsonreuters::ema::access::OmmConsumer::registerClient become invalid?

We are saving the handle returned by

thomsonreuters::ema::access::OmmConsumer::registerClient 

when we subscribe to a RIC. When we are no longer interested, we call

thomsonreuters::ema::access::OmmConsumer::unregister 

with the saved handle.

It looks like EMA reuses handles and we are facing the following issue.

  1. We subscribe to let's say instrument ABCD, we get back handle for it, let's say x.
  2. We get a onStatusMsg callback saying stream is closed, we don't have permission or the record could not be found. We queue the instrument ABCD for unsubscribe with handle x. It looks like behind the scene EMA has already unsubcribed that handle and thinks handle x is free to reuse.
  3. We subscribe to instrument EFGH, we get back handle x for it.
  4. Our queued unsubcription for instrument ABCD calls unregister with handle x. This causes unsubscribe for instrument EFGH as EMA beleives handle x is now associated with instrument EFGH subscription.
  5. We beleive we are subscribed for instrument EFGH but never get a callback as EMA already unsubscribed it.

So it looks like the handle returned by registerClient becomes invalid at some point as it is no longer associated with the instrument we subscribed for. When does it happen? Is there a documentation for it? When should we not call unregister?

Thanks.

elektronrefinitiv-realtimeelektron-sdkrrtema-apielektron-message-apic++
icon clock
10 |1500

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

Upvotes
Accepted
24.9k 86 10 22

Hi @nm

You are correct - only OpenEnum indicates the stream remains open - once the stream is closed, the handle will become invalid as the API has unregistered the handle.

OpenEnum Indicates the stream is opened and will incur interest after the final refresh. NonStreamingEnum Indicates the item will not incur interest after the final refresh - i.e stream is closed immediately after the refresh.
ClosedEnum Indicates the stream is closed.
ClosedRecoverEnum Indicates the stream is closed, typically unobtainable or identity indeterminable due to a comms outage. The item may be available in the future.
ClosedRedirectedEnum Indicates the stream is closed and has been renamed. The stream is available with another name. This stream state is only valid for refresh messages. The new item name is in the Name get accessor methods.

To expand on the Redirected : The current stream is closed and has new identifying information. The user can issue a new request for the data using the new message key data from the redirect message. This state can result from either a RefreshMsg or a StatusMsg e.g. if a RIC is renamed by the feed. You can read more about this in section 12.1.3.3 of the ETA Devguide

icon clock
10 |1500

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

Upvotes
13k 61 39 63

Hi @nm,

The register handle returned is typically used to either match up refreshes/updates to a specific item or to use it to explicitly close an open stream. The unregister call is only valid for open streams. When you register interest in an item and you receive a status code indicating the stream is closed, the handle associated with that particular item is no longer valid. As far as EMA is concerned, that handle is available for use/reuse. The closed handle should not be associated with that item anymore - it is open for reuse by EMA.

You can read more about this within section 4.1.5 within the EMA C++ Developers Guide.

icon clock
10 |1500

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

@nick.zincone.1. Thanks.

There are 5 possible stream state https://github.com/Refinitiv/Elektron-SDK/blob/master/Cpp-C/Ema/Src/Access/Include/OmmState.h#L59-L71.

  1. OpenEnum
  2. NonStreamingEnum
  3. ClosedRecoverEnum
  4. ClosedEnum
  5. ClosedRedirectedEnum

Are you saying that the handle remains valid only for #1? If I receive any other state, the handle is not valid and I should not call unregister?