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?

Hello @rajeesh.r,

Please see this prior discussion on the subject.

Hope it helps?

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.

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

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.

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

Hello @rajeesh.r,

I agree with @Alex Putkov. 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.

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