Consumer App using EMA - Timeouts

EDP.Habib.Ahsan

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>

Gurpreet

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.