Starting with client connected to an Elektron Edge Device using ETA that has a subscription to a BDS.
If the Elektron device is rebooted the client almost immediate receives a channel event specifying: RSSL_RC_CET_CHANNEL_DOWN_RECONNECTING indicating that the channel was reset by the peer.
Since the connect options have the reconnectAttemptLimit set to -1, the client will attempt to reconnect to the server at using the specified interval range of 100 to 60000 msec.
After some additional channel event messages specifying: RSSL_RC_CET_CHANNEL_DOWN_RECONNECTING indicating the client connect failed, another channel event arrives, this time specifying case RSSL_RC_CET_CHANNEL_UP.
Immediately following this the loginCallback set in the ConsumerRole specified when the rsslreactorConnect API call was made is invoked, with a status indicating: Closed/Suspect/Not entitled - text: "DACS DDS connection is down"
At this point the client assumes that the credentials specified in the original login message are no longer valid and aborts the connecton.
How is it possible to determine that the Elektron device is reporting a lack of entitlement for the specified username is due to an incomplete reboot process and that it should retry.
Further, in what way can it detect that the entitlement portion of the Edge device is back up and ready to process a login -- especially given that the login in this circumstance is happening automatically due to the reconnectAttemptLimit setting.
Should the client just use a loginFailure retry setting that inidcates that login failures are not to be trusted and should be retried a set number of times before giving up?
Or is there a way to detect that the error was ephemeral?