Session down: Did Not respond to PING REQ

eric.z.chen

Hi team,

We use SFC/TREP. We recently
encountered a few rmds disconnection issues in the UAT.

Log from our market data team (who manages the TREP insfrastructure):

<usnytrepd02.gp.ads: Info:
2017-03-09.12:36:57> Disconnected User: APP_PORTWARE_uat at position
161.3.70.59/net on channel 23 using application 256. Did Not respond to PING REQ.<END>

Log from our application server
(which connects to TREP):

12:40:39.212 ERROR [JSFC Event
Thread 0] transport.ReutersTransportLevelOneOnly - [RTI] Session DOWN: com.reuters.sfc.ssl.SSLClientConnection@6155dbea
usnytrepd02.us.hsbc Not connected: SIPC parsing error. Stopping all
adapters

12:40:40.234 ERROR [JSFC Event
Thread 0] transport.ReutersTransportLevelOneOnly - [RTI] Session UP: com.reuters.sfc.ssl.SSLClientConnection@6155dbea
usnytrepd02.us.hsbc. Starting all adapters

Can you please give me a bit more details on how the "PING REG" works? e.g., how long is the timeout.

Regards,

Eric

Find more posts tagged with

trep

infrastructure

elektron

sfc

disconnection

ping

refinitiv-realtime

Accepted answers

Jirapongse

One scenario which can trigger this issue is the JSFC Event Thread is busy processing the updates. Therefore, it is unable to send the ping response in time which causes ADS cutting the connection. Typically, we call this situation a slow consumer.

To avoid the slow consumer issue, the application must return from all RTRecordClient callback functions, such as processUpdateComplete, and processRecordSync, as fast as possible.

Therefore, the developer must remove all long processing logic, such as updating the database to another thread.

For example, in RTRecordClient::processUpdateComplete, the application can create an object which contains the updated fields and values retrieved from the record and then put that object to a queue which will be processed by another thread. This way makes sure that JSFC Event Thread will return as fast as possible.

In conclusion, if the disconnection happens infrequently (once within a few hours), you can try to extend pingInterval to avoid ADS cutting the connection.

However, if the disconnection happens frequently (every few minutes), you need to verify the application logic to make sure that JSFC callback functions return as fast as possible. Otherwise, you may reduce the number of subscribing items per application's instance.

All comments

Jirapongse

JSFC has a configuration called *pingInterval. The default value is 20 seconds. This configuration controls the amount of time (in seconds) that a connection is allowed to remain idle.

Ping messages are sent automatically between the client and server to ensure that the connection remains active. The connection times out if no response is received for three consecutive ping messages. With the default setting, it could be 60 seconds.

ADS will send the ping request message to the client every interval defined in *pingInterval configuration. Then, for each ping request, the client will send the ping response back to the server. If the server doesn't receive any ping response back from the client for three consecutive ping requests, it will cut the connection.

This could be network or application’s performance issue. The application may be busy so it can’t respond to the ping message on time.You may increase the ping interval time by using
JSFC configuration: *pingInterval.

eric.z.chen

hi jirapongse.phuriphanvichai,

Thanks for the response. When you say " client will send the ping response", does it send the PING message in the thread [JSFC Event Thread 0] (i.e., the thread which processes all market data messages from Reuters)?

I want to understand the reason for the "disconnection". In the event of disconnection, would the JSFC API always automatically reconnect?

eric.z.chen

In addition,

can you please show me the documentation/examples for JSFC API?

Jirapongse

I have tested this by suspending [JSFC Event Thread 0]. Suspending [JSFC Event Thread 0] can cause ping timeout.

Yes, after disconnection, JSFC will automatically reconnect to the server.

steven.peng

Hi @eric.z.chen,

The ping of JSFC works in the background and is usually not the concern of the application. There can be many reasons that the server not to receive the ping in time. It could be a network interruption. Or the application was busy and did not respond the ping in time. Do you have any other server log messages before the issue happened? Can you tell us more about how the application works? Is there a patent that you can re-produce the issue? What the application was doing when it happened? Can you turn on the trace and generate any trace messages?

We here in the forum will try our best to help you but I thing it will be more efficient that you open a ticket through TRDC and supply them with the information I mentioned above.

Jirapongse

To avoid the slow consumer issue, the application must return from all RTRecordClient callback functions, such as processUpdateComplete, and processRecordSync, as fast as possible.

Therefore, the developer must remove all long processing logic, such as updating the database to another thread.

In conclusion, if the disconnection happens infrequently (once within a few hours), you can try to extend pingInterval to avoid ADS cutting the connection.

EXPLORE OUR SITES