F9: Server has gone down. Will recall when a server becomes available

We have are getting data from IDN_SELECTFEED and we have created a conflation service based from IDN_SELECTFEED called IDN_X and we have 4 ROUTES to retrieve data from IDN_SELECTFEED

When RTO Route is disconnected IDN_SELECTFEED is able to seamlessly get data from other RTO Routes. However, for IDN_X it will occur: F9: Server has gone down. Will recall when a server becomes available

How can we resolve this IDN_X issue?

Find more posts tagged with

ADS

refinitiv-real-time-optimised

Accepted answers

wasin.w

Hello @weishengtay

Thank you for the confirmation. The F9 message indicates that something went wrong on the ADS (possibly the feed one) side when it encounters the route disconnected.

Did you check the IDN_X service status in the adsmon tool whether it is UP or DOWN?

I strongly suggest you contact the ADS support team to verify the issue on the ADS side.

All comments

wasin.w

Hello @weishengtay

Could you please explain more about your connection and the product that encounters the issue?

I am assuming that you are using the deployed ADS with the service name IDN_SELECTFEED which source data from RTO like the following diagram:

Service IDN_SELECTFEED: Consumer API (RFA or RTSDK) --> ADS --> RTO
Service IDN_X: Conflate from above service

When one RTO Route gone down, the IDN_X service got "F9: Server has gone down. Will recall when a server becomes available" message and never back to UP again, am I correct?

Please be informed that the "F9: Service has gone down. Will recall when service becomes available." message is generated from the ADH server. According to the ADH document, the message appears if a service goes gone down, the ADH logs this status text, and any ADS in Broker mode sends this status text.

On the API part, if an application receives this status with DataState = Suspect; StreamState = Open state, the Real-Time APIs (RFA and RTSDK) automatically recovers the item subscription for an application. An application does not need to re-subscribe item manually. However, if the service does not recover (back to UP), I strongly suggest you contact the ADS support team to verify the issue on the server side.

You can contact the ADS support team via https://myaccount.lseg.com/en/helpandsupport website.

I hope this information helps.

weishengtay

Hello @wasin.w,

Your understanding is right, however we are using ADS pop configuration

Service IDN_SELECTFEED: Consumer API (RFA or RTSDK) --> -> ADS (hub) -> ADS (feed) --> RTO / EDGE
Service IDN_X: Conflate from above service

At the ADS Feed layer, we have 4 IDN_SELECTFEED routes and at the ADS Hub layer, we have IDN_SELECTFEED as well as IDN_X conflate from IDN_SELECTFEED.

The current scenario is that at the Hub layer:

1. Both Consumer API side and ADS Hub (testclient demo tools with -X) - if service is IDN_SELECTFEED, it will seamlessly retrieve data from the other IDN_SELECTFEED routes

2. However, when the service is switched from IDN_SELECTFEED to IDN_X, the error: F9: Service has gone down. Will recall when service becomes available. persist and does not retrieve data from other routes

wasin.w

Hello @weishengtay

Thank you for the confirmation. The F9 message indicates that something went wrong on the ADS (possibly the feed one) side when it encounters the route disconnected.

Did you check the IDN_X service status in the adsmon tool whether it is UP or DOWN?

I strongly suggest you contact the ADS support team to verify the issue on the ADS side.

weishengtay

We have verified the IDN_X service status in adsmon is still showing state "Up".

In addition, we have tested in our dev environment, the error still persist. We simulate the behaviour and discovered that it took about 1 min to recover the service when the affected RTO is back to "Active" . It did not take data from the other IDN_SELECTFEED

EXPLORE OUR SITES