Session down: Did Not respond to PING REQ
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
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.
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.
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?
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.
In addition,
can you please show me the documentation/examples for JSFC API?
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.