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.
2
Answers
-
Hi Gurpreet,
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 -
Indefinitely. The response code says Open, so it will keep on trying.0
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 中文论坛