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);

Find more posts tagged with

trep

rfa

rfa-api

Accepted answers

wasin.w V3

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]

All comments

wasin.w V3

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 ###

<map>

</map>

</node>

Nipat Kunvutipongsak

Have you tried to enable data tracing parameters to view message communication as suggested by @Wasin Waeosri? Does this problem still persist?

Matthew.Logterman

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

pawel.c

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.

wasin.w V3

Hi @pawel.c

Item Subscription health

ADS Connection health

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]

pawel.c

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

wasin.w V3

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.

EXPLORE OUR SITES