Consumer App using EMA - Timeouts

I have a EMA based data consumer (snapshot) application that sends batch requests (1000 instruments in each batch) to the managed elektron feed in EaaS data center... and in return , some of the requests return status of closed/suspect/timeout :
2022-09-02 13:30:41,302 [main] WARN : Request failed: service=IDN_RDF name=AG1G.DE Response= ResponseCode=Status StatusCode=None description=Open / Suspect / None / 'Request timeout'
This error is usually encountered at the market open 9:30am EST and up to 2 hours after that. Data snapshot requests at Market close, i.e. at or after after 4pm, do not show any timeouts.
Wondering if anyone can guide me how to avoid me these timeouts? I am considering 2 possible causes:
1. We are missing a parameter in EmaConfig.xml which would allow the app to wait for longer time to get a response
2. ADS is inundated with data requests and cannot process all of them, hence returns timeouts
Below is a snapshot of the EmaConfig.xml:
<EmaConfig>
<!-- ConsumerGroup provides set of detailed configurations to be used by named consumers -->
<!-- Application specifies which configuration to use by setting OmmConsumerConfig::consumerName() -->
<ConsumerGroup>
<!-- DefaultConsumer parameter defines which consumer configuration is used by OmmConsumer -->
<!-- if application does not specify it through OmmConsumerConfig::consumerName() -->
<!-- first consumer on the ConsumerList is a DefaultConsumer if this parameter is not specified -->
<DefaultConsumer value="Consumer_1"/>
<ConsumerList>
<Consumer>
<!-- Name is mandatory -->
<Name value="Consumer_1"/>
<!-- Channel is optional: defaulted to "RSSL_SOCKET + localhost + 14002" -->
<!-- Channel or ChannelSet may be specified -->
<!-- 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_1, Channel_2, Channel_3, Channel_4"/>
<!-- Dictionary is optional: defaulted to "ChannelDictionary" -->
<Dictionary value="Dictionary_1"/>
<XmlTraceToStdout value="0"></XmlTraceToStdout>
</Consumer>
<Consumer>
<Name value="Consumer_2"/>
<Channel value="Channel_1"/>
<Dictionary value="Dictionary_1"/>
<XmlTraceToStdout value="0"/>
</Consumer>
</ConsumerList>
</ConsumerGroup>
<ChannelGroup>
<ChannelList>
<Channel>
<Name value="Channel_1"/>
<!-- ChannelType possible values are: -->
<!-- ChannelType::RSSL_SOCKET - TCP IP connection type -->
<!-- ChannelType::RSSL_HTTP - Http tunnel connection type -->
<!-- ChannelType::RSSL_ENCRYPTED - Https tunnel connection type -->
<ChannelType value="ChannelType::RSSL_SOCKET"/>
<!-- CompressionType is optional: defaulted to None -->
<!-- possible values: None, ZLib, LZ4 -->
<CompressionType value="CompressionType::None"/>
<GuaranteedOutputBuffers value="5000"/>
<!-- ConnectionPingTimeout is optional: defaulted to 30000 -->
<ConnectionPingTimeout value="30000"/>
<!-- TcpNodelay is optional: defaulted to 1 -->
<!-- possible values: 1 (tcp_nodelay option set), 0 (tcp_nodelay not set) -->
<TcpNodelay value="1"/>
<!-- CHANGEME: The Host name of the first RTDS ADS server to connect to -->
<Host value="159.43.120.11"/>
<Port value="14002"/>
</Channel>
Best Answer
-
Hi @EDP.Habib.Ahsan,
You can try to change the RequestTimeout parameter, which controls how long EMA waits before resending the request. Try setting it to 0.
The underlying issue is that ADS is unable to process all the requests - maybe due to bandwidth limitation at its connection to the headend. One solution to this problem is to pre-load the ADS cache, if your instruments are known ahead of time.
Other option is to speak with the infrastructure management, and get an endpoint which can handle your request volume. Yet another option is to partition the instruments into multiple batches, and send the subscription to multiple ADS.
0
Answers
-
Thanks for the details and options.
question: From your explanation in the first line, RequestTimeout seems to be a retry-wait parameter, true? How many times does EMA re-try a request until refresh message is received?
Thanks!
0 -
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
- 684 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
- 249 ETA
- 554 WebSocket API
- 37 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
- 643 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
- 26 DACS Station
- 121 Open DACS
- 1.1K RFA
- 104 UPA
- 192 TREP Infrastructure
- 228 TRKD
- 915 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 中文论坛