dead tics stream after some time
Hi,
TREP 2, RFA 7.6.0
We create OMMMsg ric subscription configured like below. Everything
is fine but after some time – few hours, we stop getting ticks on some random
rics. Finally we endup with dead constant values. We do not get any error, or anything significant in logs. Relogon, and everything is back
to live.
Is it
infrastructure config(some limit on subscription time???) or client?
Is there
anything like “ping” to confirm that subsribtion Is alive when waiting for
tics?
---------------------------------------------------------------------------
ommmsg.setMsgType(MsgType.REQUEST);
ommmsg.setMsgModelTypeRDMMsgTypes.MARKET_PRICE);
ommmsg.setIndicationFlags(OMMMsg.Indication.REFRESH
| OMMMsg.Indication.ATTRIB_INFO_IN_UPDATES);
ommmsg.setPriority((byte) 1, 1);
ommmsg.setAttribInfo(source, ric,
RDMInstrument.NameType.RIC);
Best Answer
-
Hi @pawel.c
Item Subscription health
Basically, you can monitor each item subscription health from incoming REFRESH_RESP, UPDATE_RESP and STATUS_RESP messages from the API. The REFRESH_RESP and UPDATE_RESP messages are incoming data messages.
The STATUS_RESP message type is used to indicate changes to each item subscription event stream or data properties. This message can convey changes in streamState or dataState object. If information is not available or the user is not entitled, this STATUS_RESP message is typically delivered to provide more detailed information to the consumer.
ADS Connection health
The application can sets up OMM Connection notifications by registering the OMMConnectionIntSpec Interest Specification. This allows the application to receive OMM Connection events that contains the connection status between the API and OMM Provider (ADS server, EZD server, etc).
Example code:
OMMConnectionIntSpec connIntSpec = new OMMConnectionIntSpec();
_connIntSpecHandle = _ommConsumer.registerClient(_eventQueue, connIntSpec, _loginClient, null);
...
public void processEvent(Event event){
...
if(event.getType() == Event.OMM_CONNECTION_EVENT){
OMMConnectionEvent connectionEvent = ((OMMConnectionEvent)event);
System.out.println(_className + ": Receive an OMM_CONNECTION_EVENT");
System.out.println("Name: " + connectionEvent.getConnectionName());
System.out.println("Status: " + connectionEvent.getConnectionStatus().toString());
System.out.println("Host: " + connectionEvent.getConnectedHostName());
System.out.println("Port: " + connectionEvent.getConnectedPort());
System.out.println("ComponentVersion: " + connectionEvent.getConnectedComponentVersion());
return;
}Example results:
//Connected to ADS
LoginClient: Receive an OMM_CONNECTION_EVENT
Name: AHS_21314::rsslConConnection
Status: { state: UP, code: NONE, text: ""}
Host: 172.20.33.11
Port: 14022
ComponentVersion: [ads3.2.0.L1.linux.tis.rrg 64-bit]
//Disconnected from ADS
LoginClient: Receive an OMM_CONNECTION_EVENT
Name: AHS_21314::rsslConConnection
Status: { state: DOWN, code: NONE, text: "Channel disconnected"}
Host: 172.20.33.11
Port: 14022
ComponentVersion: [ads3.2.0.L1.linux.tis.rrg 64-bit]0
Answers
-
Hi @pawel.c
Can you replicate this issue on demand? If so, could you please give us the RFA trace file when the problem occurs? The RFA trace file contains incoming/outgoing messages
between the API and TREP server. It will let us check this issue in detail.You
can configure the following RFA Java configurations to enable the log file<namespace>/Connections/<Connection Name>/ipcTraceFlags = 7
<namespace>/ Connections/<Connection Name>/mountTrace = True
<namespace>/ Connections/<Connection Name>/logFileName=<path to log file>### Example RFA Java Configuration for the trace file ###
<node name="rsslConnection">
<map>
<entry
key="connectionType" value="RSSL"/><entry
key="serverList" value="localhost"/><entry
key="portNumber" value="14002"/><entry key="ipcTraceFlags"
value="7"/><entry key="mountTrace "
value="True"/><entry key="logFileName"
value=".\logs\RSSL_%U.log"/></map>
</node>
0 -
Have you tried to enable data tracing parameters to view message communication as suggested by @Wasin Waeosri? Does this problem still persist?
0 -
Due to an outage of the Thomson Reuters Developer
Community email notification system from 2:30 PM CDT on November 29th until
9:00 AM CDT on November 30th we are posting to all questions updated during
this timeframe in order to ensure all customers receive all relevant email
updates. Please review this question, and its associated answers, in order to
ensure you are aware of any possible updates that may have occurred during this
outage. We apologize for the delay and any inconvenience this has caused.Matthew Logterman, J.D.
Sr. Product Manager, Thomson Reuters Developer Community
0 -
The
issue was persitant for two weeks. Now it is fine. So it must have been
something related to TREP infrastructure or network itself.Trace
will be certainly usefull in the future, we didn’t use all mentioned flags.The key question here is if there is anything like healthcheck in subscription
protocol or structure? I guess it must be because icon Is working fine under
the very same conditions.0 -
OK, summary...
Obviously all cases are different so proper trace is crucial, but the key was to have implementation of self contained connection so that't not the answer.
Answer above with administration events is fully correct in events based environment and best solution for the issue I suppose.
There is still the case when listener waits for events, get's nothing due to firewall malfunction and then the state of listener is not determined. It can be OK(no admin events, no data events), or NOT OK(data/admin events blocked in network). To cover that usual solution is heartbeat/healthcheck service, but it is reasonable to assume that high throughtput environment like Reuters can not have such services on every subscription.
Thank You,
Pawel
0 -
Hello @pawel.c
Please be informed that the communications between the application and TREP server are event based via the API. If there are any changes on the communication streams (login request accept, incoming data, incoming status, etc), the API sends those changes to the application as events. If the API does not receive data from the TREP server, the API will not send event to the application.
Regarding the connection health check, the API and ADS server uses a Ping message for used for detecting the state
of the connection between the API and ADS server. When both sides are
connecting, they will send pings to each other, and waiting for ping reply. If
there is no problem between them, the sending side will expect the ping reply
from the receiving side within the ping timeout value. If the ping reply does
not come from receiving side within ping timeout value, it is interpreted as
problem at the receiving side, and the connection is dropped. This Ping message is for each session heartbeat only, not for the item subscriptions.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
- 25 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
- 716 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 中文论坛