We ran a network test to compare what events an ETA application and an SSL application receive when connected to an Elektron server.
The tests were run with:
cnctOpts.reconnectAttemptLimit = -1; cnctOpts.reconnectMinDelay = 5000; cnctOpts.reconnectMaxDelay = 10000;
If the server is rebooted, the ETA application receives repeated RSSL_RC_CET_CHANNEL_DOWN_RECONNECTING events in the event callback until the server is back online and ready to accept connections.
Next we simulated a network outage (broken cable, switch problem, etc.) for different time intervals. The simulation was performed with the cooperation of a Reuters engineer disabling the NIC card at the Elektron server.
The result for each interval was the same, the ETA application did not receive any event callback until the NIC was re-enabled. The longest interval we tested was 15 minutes and no notification was provided to the application via its callbacks during that time.
It wasn't until the NIC was re-enabled that the application received any notification at all.
Is this by design?
Cursory examination of the reactor source code seems to indicate that this is the case (whether intentional or not)
If so our application (and your documentation) may need updating. The usefulness of the reconnect logic in the reactor is limited if the application receives no notification that the connection is no longer healthy. It would be possible to either add a watchdog thread to continuously poll the last event time for each session, or to disable the reconnect logic in the reactor.
Perhaps we've missed some setting when writing our application code.
When plan on testing again early next week with the source modified to disable the reconnect logic in the reactor to see if it receives notification that the connection was gone bad.