Consumer configuration for WarmStandby

Hello,
We use RTC, which is connected to RTO, to retrieve quotes data.
We are connecting to 2 instances of RTC with 2 instances of a client application using RTSDK Java, and we are wondering about setting up a resilient connection in all this by configuring multiple channels.
Ideally, we'd like to configure all this via EmaConfig.xml, and not programmatically.
In doing some research, I've seen two ways of doing this, but I'd like to know what the difference is between the two, and what each of the two methods offers me.
The first way is to set up a channelGroup, like this :
<Consumer>
<Name value="Consumer_2"/>
<ChannelSet value="Channel_1, Channel_2"/>
<Dictionary value="Dictionary_2"/>
<XmlTraceToStdout value="0"/>
</Consumer>
<ChannelGroup>
<ChannelList>
<Channel>
<Name value="Channel_1"/>
<ChannelType value="ChannelType::RSSL_SOCKET"/>
<Host value="a-side_RTC"/>
<Port value="14002"/>
</Channel>
<Channel>
<Name value="Channel_2"/>
<ChannelType value="ChannelType::RSSL_SOCKET"/>
<Host value="b-side_RTC"/>
<Port value="14002"/>
</Channel>
</ChannelList>
</ChannelGroup>
In my tests with this configuration, I find that when one instance of RTC is stopped, the other instance is used.
I've seen other ways of configuring, like this that I haven't tested:
<WarmStandbyServerInfoGroup>
<WarmStandbyServerInfoList>
<WarmStandbyServerInfo>
<Name value="Server_Info_1"/>
<Channel value="Channel_1"/>
<PerServiceNameSet value=""/>
</WarmStandbyServerInfo>
<WarmStandbyServerInfo>
<Name value="Server_Info_2"/>
<Channel value="Channel_7"/>
<PerServiceNameSet value=""/>
</WarmStandbyServerInfo>
</WarmStandbyServerInfoList>
</WarmStandbyServerInfoGroup>
<WarmStandbyGroup>
<WarmStandbyList>
<WarmStandbyChannel>
<Name value="WarmStandbyChannel_1"/>
<StartingActiveServer value="Server_Info_1"/>
<StandbyServerSet value="Server_Info_2"/>
<WarmStandbyMode value="WarmStandbyMode::LOGIN_BASED"/>
</WarmStandbyChannel>
</WarmStandbyList>
</WarmStandbyGroup>
So I'd like to have a comparison between the two, and please tell me what advantages each approach offers?
Many thanks in advance!
Best Answer
-
This article on resiliency can explain some of the concepts.
Essentially, in the first configuration example- the ChannelSet uses cold-standby feature. This means a connection is established and used and only upon termination of the first connection, a second connection to Channel2 will be established. So, only one connection is active at any given time.
In the warm standby mode, two concurrent connections are made simultaneously and the items are subscribed to both the channels. The standby channel is instructed to not send updates - but the connection is established and it is ready to send data when it is instructed to become a primary. The recovery on the warm standby channel will be faster then that with cold standby feature.
Now, since you are using RTSDK Java, your application doesn't need to use RTC to get data from RTO, It has the ability to directly connect and get data from RTO.
If however you intend to keep the same architecture and implement warm standby with RTC, be aware that both the RTC will open the subscription to all the instruments, and your network bandwidth requirement would double.
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
- 690 Datastream
- 1.4K DSS
- 629 Eikon COM
- 5.2K Eikon Data APIs
- 11 Electronic Trading
- 1 Generic FIX
- 7 Local Bank Node API
- 3 Trading API
- 2.9K Elektron
- 1.4K EMA
- 255 ETA
- 559 WebSocket API
- 39 FX Venues
- 15 FX Market Data
- 1 FX Post Trade
- 1 FX Trading - Matching
- 12 FX Trading – RFQ Maker
- 5 Intelligent Tagging
- 2 Legal One
- 24 Messenger Bot
- 3 Messenger Side by Side
- 9 ONESOURCE
- 7 Indirect Tax
- 60 Open Calais
- 279 Open PermID
- 45 Entity Search
- 2 Org ID
- 1 PAM
- PAM - Logging
- 6 Product Insight
- Project Tracking
- ProView
- ProView Internal
- 23 RDMS
- 2K Refinitiv Data Platform
- 714 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
- 106 UPA
- 194 TREP Infrastructure
- 229 TRKD
- 918 TRTH
- 5 Velocity Analytics
- 9 Wealth Management Web Services
- 95 Workspace SDK
- 11 Element Framework
- 5 Grid
- 19 World-Check Data File
- 1 Yield Book Analytics
- 48 中文论坛