For a deeper look into our Eikon Data API, look into:

Overview |  Quickstart |  Documentation |  Downloads |  Tutorials |  Articles

question

Upvotes
Accepted
JIAN.DU avatar image
39 ●3 ●6 ●5

Heartbeat for Eikon API Proxy

Hi,

Sometimes I have found that the Eikon API proxy would become unresponsive, is there a recommended way to send a heartbeat through to Eikon API Proxy (embedded in Eikon Desktop?) Alternatively I could try get_data and catch any exceptions, however sometimes have found that get_data can fail due to non-responsiveness. Just looking for a simple way to check that API is ready and responsive.

Currently just checking if port 9000 is alive, wondering was there another way to check?

set_app_key doesnt raise any exceptions (only the fetching data functions do), just prints messages like below so believe can't catch exception without monkey patching the eikon library.

Timeout on checking port 36036
Error: no proxy address identified.
Check if Eikon Desktop or Eikon API Proxy is running.
Port number was not identified, cannot send any request
eikoneikon-data-apiworkspaceworkspace-data-apirefinitiv-dataplatform-eikonpython
icon clock
10 |1500

Up to 2 attachments (including images) can be used with a maximum of 5.0 MiB each and 10.0 MiB total.

1 Answer

Upvotes
Accepted
Alex Putkov.1 avatar image
39.2k ●75 ●11 ●27

There's no recommended way to do this. Personally I don't quite see the point. If you determine that API Proxy is not responding to the heartbeat, what are you going to do? And why wouldn't you do the same thing when the request fails. What's the advantage of dealing with the failed heartbeat over dealing with a failed request? I only see disadvantages: when the request fails you know you have a problem, and the problem is you didn't get the data you need. So you must deal with this problem. When a heartbeat fails it's quite possibly a temporary issue that may remedy itself by the time you need to send your data requests. What could be the reason for API Proxy process to stop listening on the local port? A process is starved of resources perhaps? Or the process is hung. Either way I don't see why you'd want to know about it and deal with it before you need to retrieve the data.
You're right, set_app_key doesn't raise an exception, it outputs messages to the logger named pyeikon. You can capture messages created by a Python logger by adding a handler to the logger. Here's an example you can easily adapt for your purposes: http://alanwsmith.com/capturing-python-log-output-in-a-variable
This way you could use set_app_key method as your heartbeat, but as I said, I don't quite see the point.

icon clock
10 |1500

Up to 2 attachments (including images) can be used with a maximum of 5.0 MiB each and 10.0 MiB total.

JIAN.DU avatar image JIAN.DU

Thanks. Sending a request would sometimes time out or return a 500/503 error. I was looking for a method whereby the check is robust against the above errors.

Alex Putkov.1 avatar image Alex Putkov.1 JIAN.DU

Python library sends HTTP requests to API Proxy running on Eikon machine and listening on the local port. The API Proxy passes those HTTP requests to the Web service that delivers the data. I think the first thing to determine is whether the error comes from the API Proxy or from a Web service that provides the data. I think it's most likely the latter, in which case the only reliable check is the data request.

Alex Putkov.1 avatar image Alex Putkov.1 JIAN.DU

The way to determine whether the error comes from the API Proxy or the API Proxy just passes through the error generated by the Web service is to use Fiddler or another HTTP analyzer to see if the HTTP request to the Web service goes on the wire.

JIAN.DU avatar image JIAN.DU Alex Putkov.1

Thanks Alex. Putting in a backoff strategy worked as well. I will take a look at analysing the requests to see if there's some underlying cause.

Click below to post an Idea Post Idea