Inconsistent failover behavior depending of port settings in dacsDaemon property

gaetan.vaysse

We have an application that is connecting to a DACS daemon, using the RFA Java libs. We want to enable failover but are seeing a weird behavior when failing over one IP to the other.

We provide a set of hostname:port to the dacsDaemon property, like this (note the different port):

test1:8212,test2:8211

It appears that if we try to connect to connect/logs onto the DACS:

• if the first host in the list is working, the connection is established
• if the first host is down, the connection never establishes to the second one
• on the other hand, if the first host is down but both entries have the same port (test1:8211,test2:8211), we seem to connect properly to the second one.

Is it a known behavior? Is there anything to change to get a proper failover despite the different ports?

zoya faberov

Hello @gaetan.vaysse ,

Please find the hosts configuration description in OpenDACS Developers guide:

I do not think you are using the hosts configuration in the expected way, which results in unexpected behavior. The separate second port setting is not supported, and when you define with two ports, only the expected one port is applied.

gaetan.vaysse

Thanks Zoya for your answer! But we are using the DACS client in the RFA Java libs, and the option we are using is dacsDaemon, not hosts, to provide host/ports. That said, your explanation seems to match the observed behavior: do you know if the behavior is supposed to be the same in our case?

zoya faberov

Hello @gaetan.vaysse ,

As you question was asked in OpenDACS forums, I have assumed, incorrectly, that you were integrating with OpenDACS API

Please confirm what version of RFA you are using and what infra you are connecting to, and any other relevant use case information, so we can try to help.

ADS will establish and handle the connection to DACS on behalf of an RFA client, for the purpose of the entitlement checking. As RFA client only needs to connect to ADS, in my understanding, you would not need to explicitly establish a connection to dacs sink daemon and design for fault tolerance. That is, if my understanding of the question is correct now?

gaetan.vaysse

Hello Zoya (and thanks for the time you took to answer, btw). We are using RFA Java 8.1.0.E2, connecting to an ADS instance.

As to why we do connect to the DACS sink directly, it's because we have client processes connecting to a gateway that itself connect to a Reuters source; we mutualize subscription to pull data only once, so we need to validate user subscription at the gateway entry point. So removing that dacs check at subscription is not really an option to maintain accurate usage details...

zoya faberov

Hello @gaetan.vaysse ,

OpenDACS and OpenDACS Permission Server are the recommended approaches to implement data distribution that is data distribution compliant. Two articles that could help introduce the topic Open DACS and Open DACS Permission Server and in-depth Open DACS Application Best Practice.

Per current API Compatibility Matrix all versions of RFA API are Legacy.

RFA 8 does not have the configuration per Connection to enable direct DACS check, it is only RFA 7.6, or perhaps older.

I would suggest not to invest the time and effort to add fault-tolerance to legacy RFA driven distribution entitlement check.

As a long term strategy, would plan to migrate to strategic APIs, and would like to include an article to introduce the topic Migrating from Refinitiv Legacy to Strategic APIs and in-depth Migrating from the Legacy Robust Foundation API (RFA) to the Enterprise Message API (EMA)

Hope that this information helps

gaetan.vaysse

Hello Zoya, thanks for the articles! Indeed RFA is getting deprecated as shown in the matrix: do you know if there is already an EOL date? I guess longer term we'll have to switch to RFA to EMA + ODPS.

RFA 8 does not have the configuration per Connection to enable direct DACS check, it is only RFA 7.6, or perhaps older.

I'm not sure I follow, but RFA 8 definitely allow to connect to a sink by instantiating com.reuters.rfa.dacs.AuthorizationSystem and com.reuters.rfa.dacs.AuthorizationAgent instances. That part works, and has worked for some time: our only issue is that weird failover behavior, where it seems that only one port in the "host:port" list is used. We wonder if we do something wrong or if it's a known limitation, in which case we'll see what's our next step.

zoya faberov

Hello @gaetan.vaysse ,

There are no RFA EOL dates yet, they are expected to be announced.

Please be assured that as a customer you will be informed of EOL and consequently will have time to migrate to a strategic API. There will be a Product Change Notification letter issued to the customers when EOL dates come out.

I think, it is good to be informed, to plan the migration as to allow you time for solid implementation and testing, rather then to have to potentially rush it in order to always be on a supported API.

---

Thanks for confirming, that you are using RFA API to subscribe and OpenDACS to process DACS entitlements and to distribute the data in a compliant way, via AuthorizationSystem. Please see Open DACS -> Tutorial 1 – DACS Daemon Connection

Therefore you should be using hosts parameter described above to define the connection via Open DACS to multiple hosts, however, please confirm if this is the case?