EMA Channel failover
Hello,
I have a EMA Consumer based application. I am using a ChannelSet with two channels (two different IP addresses). However, when the first channel in the ChannelSet goes down (I get a 'ChannelDownReconnecting event on channel Channel_1' message, and 'Channel is down', etc), my subscriptions do not automatically failover to the next Channel in the ChannelSet. I'm wondering if this is the expected behaviour, or is the ChannelSet only useful when we make the initial connection? (i.e. detecting if one is down then rather than failover).
There is also an example on doing failover here: https://developers.refinitiv.com/en/article-catalog/article/how-implement-service-resiliency-ema-consumer-application I'm wondering if need to implement similar logic in order for the failover to work.
Thanks!
Best Answer
-
Hello @davinb,
Failover to the next channel in ChannelSet should happen, if the initial connection did not succeed or if the established connection is broken. The article referenced discusses how to achieve service resilience, when the channel remains up, however, the service that we require from it goes down.
My thinking is, that if the failover does not seem to happen in a custom consumer, I would run a quick test with a standard example consumer that came with RTSDK, I would use Market Price 110 File Config, pointing it via Consumer configuration at your ChannelSet, I would also make sure to enable Xml tracing.
For example:
<Consumer>
<Name value="Consumer_11"/>
<!-- ChannelSet specifies an ordered list of Channels to which OmmConsumer will attempt to-->
<!-- connect, one at a time, if the previous one fails to connect-->
<ChannelSet value="Channel_12, Channel_13"/>
<Dictionary value="Dictionary_1"/>
<XmlTraceToStdout value="1"/>
</Consumer>One option to test is to simulate the disconnect by interrupting network connectivity, observing Channel Down and after a short period of time ( 30 sec?) restoring network connectivity. EMA should try reconnecting to the original channel first, and failing that, reconnect to the second channel next, which you should see via tracing enabled. The default behavior of EMA is single-open (see more on single-open in RDM Usage Guide, so once the channel is re-established, the items should be re-subscribed.
If the channel failover and item recovery work as expected with the example consumer and test configuration, the next step could be verifying your custom consumer, to understand why the failover is not happening as expected, by comparing with the working simple example.
Hope this suggestion helps
0
Answers
-
OK, so there is a difference between the Channel and a Service. If I get a message saying 'Service for this item was lost' or 'No matching service present' would the service failover described in the above mentioned example help resolve this ?
0 -
Hello @davinb ,
Yes, they are different, let me try to explain?
Unless the connection is lost, ChannelSet -driven failover will not happen. Only on connection loss EMA will attempt reconnect to the endpoint first, and failing that, attempt the connection (failover) to the next channel that is defined on the ChannelSet.
This is because, in a general case, multiple services can be made available via connectivity endpoint/distribution infrastructure. Therefore, one service being down does not constitute the complete loss of service.
If you require, to force the reconnect to a different endpoint, based on a loss of specific service, this is the case when the article linked would describe how to implement this requirement.
Hope this explanation helps?
0 -
Yes, thank you for the explanation
0
Categories
- All Categories
- 3 Polls
- 6 AHS
- 36 Alpha
- 166 App Studio
- 6 Block Chain
- 4 Bot Platform
- 18 Connected Risk APIs
- 47 Data Fusion
- 34 Data Model Discovery
- 685 Datastream
- 1.4K DSS
- 615 Eikon COM
- 5.2K Eikon Data APIs
- 10 Electronic Trading
- Generic FIX
- 7 Local Bank Node API
- 3 Trading API
- 2.9K Elektron
- 1.4K EMA
- 252 ETA
- 556 WebSocket API
- 38 FX Venues
- 14 FX Market Data
- 1 FX Post Trade
- 1 FX Trading - Matching
- 12 FX Trading – RFQ Maker
- 5 Intelligent Tagging
- 2 Legal One
- 23 Messenger Bot
- 3 Messenger Side by Side
- 9 ONESOURCE
- 7 Indirect Tax
- 60 Open Calais
- 275 Open PermID
- 44 Entity Search
- 2 Org ID
- 1 PAM
- PAM - Logging
- 6 Product Insight
- Project Tracking
- ProView
- ProView Internal
- 22 RDMS
- 1.9K Refinitiv Data Platform
- 652 Refinitiv Data Platform Libraries
- 4 LSEG Due Diligence
- LSEG Due Diligence Portal API
- 4 Refinitiv Due Dilligence Centre
- Rose's Space
- 1.2K Screening
- 18 Qual-ID API
- 13 Screening Deployed
- 23 Screening Online
- 12 World-Check Customer Risk Screener
- 1K World-Check One
- 46 World-Check One Zero Footprint
- 45 Side by Side Integration API
- 2 Test Space
- 3 Thomson One Smart
- 10 TR Knowledge Graph
- 151 Transactions
- 143 REDI API
- 1.8K TREP APIs
- 4 CAT
- 27 DACS Station
- 121 Open DACS
- 1.1K RFA
- 104 UPA
- 193 TREP Infrastructure
- 228 TRKD
- 917 TRTH
- 5 Velocity Analytics
- 9 Wealth Management Web Services
- 90 Workspace SDK
- 11 Element Framework
- 5 Grid
- 18 World-Check Data File
- 1 Yield Book Analytics
- 46 中文论坛