Request for assistance with API disconnect due to no server ping
RFA Version : rfa8.1.0.L1.linux statically linked
We connect successfully with no subscription, and about 2 hours later, we create first subscription, immediately after, we get following message.
From:RSSL_Adapter Id:20104 EventType:3 Text: [Tue Jun 9 08:01:22 2020]: (ComponentName) RSSL_Adapter: (Severity) Error: Ping has not been received by this connection "Connection_RSSL" within negotiated ping timeout. Connection will be shut down. Negotiated ping timeout is set to: 30
From:RSSL_Adapter Id:10105 EventType:3 Text: [Tue Jun 9 08:01:22 2020]: (ComponentName) RSSL_Adapter: (Severity) Error: 10105 (Default::Connection_RSSL ld6mdsads1p.ldr.jefco.com:14002)
From:RSSL_Cons_Adapter Id:6015 EventType:1 Text: [Tue Jun 9 08:01:22 2020]: (ComponentName) RSSL_Cons_Adapter: (Severity) Information: Initialization of RSSL_Cons_Adapter "Default::Connection_RSSL ld6mdsads1p.ldr.jefco.com:14002" failed, will retry in State: "Down" StatusCode: "None" StatusText: Connection down milliseconds
the threading model id "dual" and we do use EventQueues.
We need to reconnect, and we do not get same issue after that for the rest of trading day.
Any guidance and direction would be highly appreciated.
Thanks, Sanjay
Please be informed that a reply has been verified as correct in answering the question, and has been marked as such. Thanks, AHS
Hello Sanjay @sgirdhar,
The behavior that you describe does not sound common or intuitive and most likely is not directly related to RFA API.
I would approach troubleshooting this two-fold.
1. Run another client, not custom, for test purposes, start it, login, and only send the first subscription request after 2 hours, and see if the behavior is the same. I would try testing with one of the consumer examples that came with RFA SDK, and introduce delay of 2 hrs (would do a reasonable sleep in a loop), prior to subscription or thinking perhaps rmdstestclient that comes with Infra Tools package, using it in interactive mode.
2. I would report this behavior to your local market data group/admin, people who maintain infrastructure, local TREP. Try to find out how these daily disconnects are reflected in the infrustructure log, and if nothing definite, if additional logging can be added to help better understand the reasons behind them.