handling if Capabilities not available in Source Directory Info filter response

How should a consumer handle if a Source
Directory Info filter response indicates that a domain
the consumer interested is not available at initialization? Should the service be considered not available?

Is it possible that capability
of a service change at runtime as an update payload such as a domain is no longer available in the service? If so what would happened to existing streams opened with the domain affected and how should a consumer handle that scenario?

Find more posts tagged with

elektron

Service

elektron-sdk

refinitiv-realtime

elektron-transport-api

eta-api

rrt

source-directory

Accepted answers

Jirapongse

I assume that you are using TREP as an infrastructure.

The application should check the available capabilities of the service before sending an item request. From my test, if the application still sends an item request to the unavailable capability, TREP will send the status message back with this status text: "No servers available that support this domain."

<statusMsg domainType="RSSL_DMT_MARKET_PRICE" streamId="6" containerType="RSSL_DT_NO_DATA" flags="0x28 (RSSL_STMF_HAS_MSG_KEY|RSSL_STMF_HAS_STATE)" dataState="RSSL_DATA_SUSPECT" streamState="RSSL_STREAM_OPEN" code="RSSL_SC_NONE" text="No servers available that support this domain."  dataSize="0">
    <key  flags="0x7 (RSSL_MKF_HAS_SERVICE_ID|RSSL_MKF_HAS_NAME|RSSL_MKF_HAS_NAME_TYPE)"  serviceId="4591" name="TEST" nameType="1"/>
    <dataBody>
    </dataBody>
</statusMsg>

Regarding the change of capability in the source directory update message, I can send a source directory update message to TREP to remove the capability of the service. However, from my test, TREP is still able to provide the data for that capability if the provider doesn't close those item streams.

Therefore, if the provider would like to remove the capability from the service, it should close all subscribed item streams of that capability too.

Moreover, if you are using TREP, you should contact the TREP support team via MyRefinitiv to verify how TREP handle this kind of usage.

All comments

umer.nalla

Hi @tinmyo.win

This is a tricky one to answer.

It is a responsibility of any Provider application (source) to advertise its capabilities including which domains it supports.

A service can provide more than one domain, so in theory, if one expected domain is not available - but other domains are still available then you cannot consider the service as unavailable.

In theory, yes, you could receive an updated Source directory during runtime with a revised domain list.

In reality, I am not sure when this would happen and therefore how to handle it....

If the service is a Refinitiv service, then you would need to contact Refinitiv support and ask them to explain. I would expect that if some fault scenario did result in one or more domains being temporarily unavailable, Refinitiv would be making all efforts to restore the domains as soon as possible.
If you were consuming an internal service, then you would need to contact your own internal service provider to investigate & resolve the issue.

In terms of existing streams, in theory, if a service did suddenly stop supporting an existing domain, then it follows that it should not be able to continue updating any existing streams of that domain type. I would expect the service to close the item streams (or possibly mark them as Suspect ?). This would be the responsibility of the Provider/source application and the consumer would just respond accordingly.

To be honest, I do not recall an incident of the type you are describing - that's not to say it has never happened.

Jirapongse

I assume that you are using TREP as an infrastructure.

<statusMsg domainType="RSSL_DMT_MARKET_PRICE" streamId="6" containerType="RSSL_DT_NO_DATA" flags="0x28 (RSSL_STMF_HAS_MSG_KEY|RSSL_STMF_HAS_STATE)" dataState="RSSL_DATA_SUSPECT" streamState="RSSL_STREAM_OPEN" code="RSSL_SC_NONE" text="No servers available that support this domain."  dataSize="0">
    <key  flags="0x7 (RSSL_MKF_HAS_SERVICE_ID|RSSL_MKF_HAS_NAME|RSSL_MKF_HAS_NAME_TYPE)"  serviceId="4591" name="TEST" nameType="1"/>
    <dataBody>
    </dataBody>
</statusMsg>

Therefore, if the provider would like to remove the capability from the service, it should close all subscribed item streams of that capability too.

Moreover, if you are using TREP, you should contact the TREP support team via MyRefinitiv to verify how TREP handle this kind of usage.

EXPLORE OUR SITES