How to know when BDS (SymbolLists) are available after Elektron Server reboot
We've noticed that the if an Elektron Server reboots (as ours did this weekend for a security patch), the client code that communicates with the server will automatically reconnect when the server comes back up, processing a series of RSSL_RC_CET_CHANNEL_DOWN_RECONNECTING messages and backing off until the server is up again.
Once the connection is resestablished, RSSL_RC_CET_CHANNEL_UP and RSSL_RC_CET_CHANNEL_READY, the client will try to resubscribe to the symbols lists (BDS) it was subscribed to before the server went down.
When such a subscription is attempted, the server will respond with a "NOT FOUND" message. If the request is resubmitted a few minutes later, the request for the same symbol name will succeed. It appears that the ELEKTRON server is reporting that it is up and ready before the portion of the code that services BDS names (symbol lists) has initialized.
Would it be possible to either:
* detect that the server was rebooted so that the (re)subscribe requests to for the symbol lists can be delayed a configurable period of time
* receive notification that the BDS system is up and ready to process requests
( receive a notification that the BDS query failed because the portion of the Elektron Server that services them is not up yet
* delay notification of either UP or READY until the entirety of the Elektron Server is actually UP and READY (including the portion that processes BDSes)
Hi @Joe.Ferraro
Based on the status values you mention, I assume you are using the Value Added components in your application.
Are you processing the Directory and then confirming that the serviceState is Up and Accepting Requests - for the service that you are using for the BDS request?
See the method directoryMsgCallback in the rsslDirectoryHandler.c file of the VAConsumer example.
I've updated the code with some additional logic based on your response and will let you know if the addition of that check / callback logic fixes the problem.
I've added some additional code based on the response above. We're scheduling a reboot test with Reuters to see if that change to the code will fix the problem.
@Ulmer.Nalla
We did the reboot test and the server responded differently. This is the first time this error occurred during reconnect login after a reboot.
Rather than pose the new question here, I'll just post a link to it:
https://community.developers.thomsonreuters.com/questions/14167/how-to-detect-that-a-login-callback-specifying-not.html
Once we work past the new problem, I'll update this question with additional information.