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.
2
Categories
- All Categories
- 6 AHS
- 37 Alpha
- 161 App Studio
- 4 Block Chain
- 4 Bot Platform
- 16 Connected Risk APIs
- 47 Data Fusion
- 30 Data Model Discovery
- 608 Datastream
- 1.3K DSS
- 577 Eikon COM
- 4.9K Eikon Data APIs
- 7 Electronic Trading
- Generic FIX
- 7 Local Bank Node API
- Trading API
- 2.7K Elektron
- 1.3K EMA
- 236 ETA
- 519 WebSocket API
- 33 FX Venues
- 10 FX Market Data
- 1 FX Post Trade
- 1 FX Trading - Matching
- 12 FX Trading – RFQ Maker
- 5 Intelligent Tagging
- 2 Legal One
- 20 Messenger Bot
- 2 Messenger Side by Side
- 9 ONESOURCE
- 7 Indirect Tax
- 59 Open Calais
- 264 Open PermID
- 39 Entity Search
- 2 Org ID
- PAM
- PAM - Logging
- 8.4K Private Comments
- 6 Product Insight
- Project Tracking
- ProView
- ProView Internal
- 20 RDMS
- 1.4K Refinitiv Data Platform
- 367 Refinitiv Data Platform Libraries
- 3 Refinitiv Due Diligence
- LSEG Due Diligence Portal API
- 3 Refinitiv Due Dilligence Centre
- Rose's Space
- 1.1K Screening
- 18 Qual-ID API
- 13 Screening Deployed
- 23 Screening Online
- 10 World-Check Customer Risk Screener
- 990 World-Check One
- 44 World-Check One Zero Footprint
- 45 Side by Side Integration API
- Test Space
- 3 Thomson One Smart
- 1.2K TR Internal
- Global Hackathon 2015
- 2 Specialists Who Code
- 10 TR Knowledge Graph
- 150 Transactions
- 142 REDI API
- 1.7K TREP APIs
- 4 CAT
- 21 DACS Station
- 117 Open DACS
- 1.1K RFA
- 103 UPA
- 172 TREP Infrastructure
- 224 TRKD
- 886 TRTH
- 5 Velocity Analytics
- 5 Wealth Management Web Services
- 59 Workspace SDK
- 9 Element Framework
- 5 Grid
- 13 World-Check Data File
- Yield Book Analytics
- 46 中文论坛