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]

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>

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

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.

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

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.