How to manage dictionary across various services and connections
I use ETA C++ API in Linux. We use EaaS (EMS) service that has multiple connection points across multiple data centers.
Since the serviceId is used when requesting data dictionary, does the client application need to download dictionary for every service id in the same connection and use it to decode response for the respective services ?
What is the best practice for an ETA application in handling data dictionary across data centers for the same services ?
In other words, when my application fails over to a different IP in the same or different data center, can it reuse the dictionary for the same service Id between different ADS servers.
At any point of time, an ETA subscriber client is connected to only one infrastructure, via ADS. If a disconnect happens, followed by the reconnect, an ETA application is responsible for handling it, i.e. subscribing to and processing off, source directory and data dictionaries.
In the case of EMS infrastructure, yes, we expect the subscriber to get seeded with exact same dictionaries, but just in case an update took place just at the moment when the subscriber reconnected, I would pursue a consistent and safe approach, of requesting directory and dictionaries, on any connect, including a reconnect.
1. In case of EMS infrastructure, if the server provide data for multiple EMS services, do I need to request data dictionary for each service on a single connection ?
2. when you say "we expect the subscriber to get seeded with exact same dictionaries", are you saying that individual server IP's from different data center will share the same dictionary ?
3. This is a follow up question to #2. I'm planning to have my client application maintain a open connection to multiple IP's (for warm standby) from different data center for quick recovery. If the IP (primary) that I use to service my request goes down, I would like to route all my request to the second in line IP. In this case, I don't make a new connection that would initiate directory and dictionary requests. What do I do in this case ?
1. The data dictionaries (field dictionary and enum dictionary) are per connection to the infrastructure, rather then per service. So no.
2. I expect EMS hosted infra to supply the latest general data dictionary. But, you want to write defensive, fully safe solution, and be prepared even against a rare contingency, when updates are applied to the infrastructure, etc. Also what if you at some point decide to work with a deployed infra? So, on establishing connection, we suggest to request the dictionaries.
3. Following up on 2, in the solution when you are looking to have two connections to two different infrastructures, I would assume nothing about the same dictionary being very likely, when the app establishes the connection to the infra, the app requests source directory and dictionaries from that infra, and uses for subscriptions to that infra.
Is it possible to get an update for data dictionary on a open connection ?
Will TR disconnect the client before updating data dictionary forcing the client to re-initialize and re-request data dictionary ?
Refer to RDMUsageGuide in RFA package, the dictionary domain doesn't use update message.
Hello @RAJ
Let me address the follow-up questions,
RDM Usage Guide explains this aspect in the following passage:
"
Though updates are not sent on dictionary streams, Thomson Reuters recommends that the consumer make a streaming request (setting ReqMsg.InterestAfterRefresh to true) so that it is notified whenever the dictionary version changes.
"I.e. the dictionary update will not be published on the open stream. In the extremely rare event that the dictionary version changes on the infrastrcuture, the consumer will be notified on the open stream. To provision for this, the subscriber would need to re-request the dictionary.
There is not explicit provision to disconnect the client on the dictionary update.
Please keep in mind that marking your follow-up question as the correct answer is misleading to other developers, and effectively closes the discussion, does not seem you intend this?