Eikon .NET API crash recovery

I am an Eikon user. My application requires a robust connectivity to the market data source. While simulating an Eikon crash scenario (killing the Eikon process from task manager) I noticed some inconsistent behaviour. At some times Eikon restarted itself immediately upon killing the process but most of the times nothing happens. Most importantly DataServices.Instance.StateChanged event does not fire to indicate the service status change and the DataServices.Instance.State says Connected also DataServices.Instance.IsInitialized is true. Is there a better approach to ensure Eikon is up and running ?

Find more posts tagged with

python

eikon

resilience

workspace

eikon-data-api

refinitiv-dataplatform-eikon

workspace-data-api

Accepted answers

zoya faberov

Hi Rajeesh @rajeesh.r,

Would it make sense, for your use case, periodically, to issue a subscribe that we can think of as test request, can be a subscription to a RIC that you do not need, and then stop it, but does not have to be, can be a symbology request, it should provide you with the same info, whether your Eikon is running as per Alex's suggestion on the other thread?

All comments

zoya faberov

Hello @rajeesh.r,

Please see this prior discussion on the subject.

Hope it helps?

rajeesh.r

Hi Zoya,

thanks for the link. Apologies I didn't clarify that mine is a WPF application. All the status change events are received as expected even without using Dispatcher.PushFrame(frame).

I mean if I shut down Eikon or disconnect the network, I get notified inside the application. The only scenario that doesn't work is a crash of Eikon which I simulated by killing the process. Please note that I also tried manually managing the event loop as suggested in the link but that also didn't work.

I was wondering if there is a recommended approach to recover after an Eikon crash?

Regards,

Rajeesh

zoya faberov

Hi Rajeesh @rajeesh.r,

Yes, Eikon can only communicate it's StateChanged if it is alive, so this state-tracking approach should track Eikon disconnects and Eikon exists, not a process kill.

If you are looking to detect and report a crash, you may have to track it via other means. And this is not something that you will encounter often, so not sure if this is something that makes sense to handle in an app.

One way I can think of is running a system shell command, for example,

tasklist | findstr Eikon

periodically, and if it's not there, alerting, such as sending an email to you.

However, in my opinion, not sure this is justified, in terms of coding required, considering that you will not be able to fully automate the recovery, trigger the restart of the Eikon and loggin in a user. I.e. a manual intervention will still be required down the line. But you can decide if this is something to explore.

rajeesh.r

Hi Zoya,

The api call DataServices.Instance.Initialize("appname") does recover Eikon automatically or at least prompts to the login screen if unable to login automatically. I did not write any specific code to handle recovery. But more than recovery, my objective is to somehow notify the user that the connection might be down due to a bg process crash.

I thought about monitoring processes but Eikon spawns up about 30 odd processes for me. If by any means, we can identify the key process managing connections here, that would be a win.

again, thanks for your help.

regards,

Rajeesh

zoya faberov

Hi Rajeesh @rajeesh.r,

I am still not convinced that this is worth implementing, as Eikon just dying is a very rare occurrence. Eikon losing connectivity or self-exiting on certain errors, or self-restarting is much more common.

However, from my observation:

One or more of Eikon.exe processes are required for the current version of Eikon to be running, and there can be many accompanying EikonBox.exe and EikonBoxNet.exe running at any given time.
If none of Eikon.exe are running, then Eikon is not running.
The behavior and naming will likely be different with the next generation of the product, Refinitiv Workspace.

rajeesh.r

Last question, does any of the processes publishes heartbeats that can be subscribed to ?

zoya faberov

Hello @rajeesh.r,

I agree with @Alex Putkov.1 suggestion, discussed in this thread - rather then heartbeat, watching state as discussed above and handling request fail together, should cover the requirements for application robustness and failure notification.

rajeesh.r

Hi Zoya,

Let me explain my scenario if that makes it clearer. My application subscribes to some rics on startup. This request is sent only once. On any change of state resulting in a disconnect, I refresh the connection and subscriptions. Works perfectly.

When Eikon crashes (although rare), my application doesn't know it did. The user restarts Eikon Desktop on their own but my application still keeps thinking the old instance is up and running as the DataServices.Instance.State still says so. At this time my application seems to be running but is disconnected to the current instance of Eikon. There is no way to notify the user that my application is not updating realtime. This is definitely a problem.

Checking for failed request and state is not sufficient as the state is not changing on crash and request is not sent all the time. Dealing with failed request and a failed heartbeat is different thing.

Really appreciate your support so far. Please feel free to close this thread.

Regards,

Rajeesh

zoya faberov

Hi Rajeesh @rajeesh.r,

EXPLORE OUR SITES