Hi @mangesh

Q 1: Is the connectionTimeout setting for the total time for the connection (login, directory...) or is it just for the login ?

Answer: The connectionTimeout set a time that the API uses for "establishing a connection to the Provider IP and RSSL port" only, not include the login and on going process.

Q 2: Is there a timeout that I can set in properties that would control the maximum time RFA tried to connect to the next provider before moving on to the next provider in the list?

Answer: The maximum time RFA tries to connect to each server in the list can be set via "connectionTimeout" parameter. After all servers in the list are tried, the API waits for "connectRetryInterval" time to start a new try with the first server in the list.

example:
serverList: "A,B,C" 
connectionTimeout: 10000 (10 seconds)
connectRetryInterval: 30000 (30 seconds)

1. firstly the API connects to server A
2. the API waits for 10 seconds, then logs "connection fail for server A"
3. the API connects to server B
4. the API waits for 10 seconds, then logs "connection fail for server B"
5. the API connects to server C
6. the API waits for 10 seconds, then logs "connection fail for server C"
7. the API waits for 30 seconds, then connects to server A again

I am checking for the rest of question.

Please note that the API does not failover to the next ADS in your scenario because the "actual network connection" between the API and ADS IP/Port is still alive. The "disconnect" means a net connection between the ADS IP and Port with the API machine is disconnected.

Did you check on your ADS to see why it does not send Service Directory refresh message to the API yet?

Hi @mangesh

The API failover is controlled by the following configuration parameter.

• connectionTimeout: The time (in milliseconds) to wait for a connection attempt to succeed. After a connection has been established, this value is used to set a timer to check for 3 consecutive missed pings. The default value is 10000
• maxRetryCount: Set the maximum number of times RFA will retry the unsuccessful connection. "-1" means retry indefinitely, "0" means no retry. If connection failed, RFA won’t retry. The default value is "-1"
• connectRetryInterval: Time in milliseconds to wait before attempting to recover a failed RSSL connection. This controls how often RFA will attempt to recover a failed connection, after it has been established.This is only used after all servers in the serverList have been attempted. The default value is 15000 (15 seconds)

Basically, the connection process are following steps

1. The API sends LOGIN request to the ADS
2. The ADS sends LOGIN response back to API

Then the API automatic sends DIRECTORY request to ADS. However, the application can manual requests DIRECTORY information to the ADS. Does your application lets the API request DIRECTORY information or manual request it?

Can you replicate this issue on demand in any controlled environment? If so, could you please enable the RFA trace file that will let us check the issue in detail? You can configure the following RFA Java configurations to enable the XML trace file

• <namespace>/Connections/<Connection Name>/ipcTraceFlags = 23
• <namespace>/ Connections/<Connection Name>/mountTrace = True
• <namespace>/ Connections/<Connection Name>/logFileName=<path to log file>

Hi @mangesh I have replicated the scenario with RFA Java StarterConsumer-StarterProvider_Interactive. If the provider does not send the DIRECTORY response to the API, the API will send the Status message

{OPEN, SUSPECT, NONE, "Waiting for service <service name> UP. Item recovery in progress..."} 

to the application if the application subscribes data.

The API also will not perform a failover because "a connection" between the API and Provider still alive. It keeps waiting for the DIRECTORY response message from the Provider. The API switches to the next Provider when it "disconnect" with the current Provider only.

Hi @Wasin,

Thanks for your response. It was really helpful in understanding what happens when we see the lock.

Our application does a manual request for Login, Directory, Dictionary (we don't have the dictionary stored locally).

You had mentioned the following -

"The API also will not perform a failover because "a connection" between the API and Provider still alive. It keeps waiting for the DIRECTORY response message from the Provider. The API switches to the next Provider when it "disconnect" with the current Provider only."

connectionTimeout: The time (in milliseconds) to wait for a connection attempt to succeed.

How long will the application wait for the directory message? When RFA api fails over from one provider to another, its completely a RFA only process. Is there a timeout that I can set in properties that would control the maximum time RFA tried to connect to the next provider before moving on to the next provider in the list. Is the connectionTimeout setting for the total time for the connection (login, directory...) or is it just for the login ?

Its not possible for us to enable RFA level logs in PROD without impacting clients. We will try to create something that will mimic the same scenario.

Hi @mangesh

Q: How long will the application wait for the directory message?

RFA requests for the directory message directly. The application simply registers interest in receiving the directory updates. There is no explicit timeout for a directory request but would fall under that standard item request timeout. The itemRequestTimeout configuration parameter is set to a default of 45s.

Q: Is there a timeout that I can set in properties that would control the maximum time RFA tried to connect to the next provider before moving on to the next provider in the list.

The connectRetryInterval configuration parameter is the time in milliseconds to wait before attempting to recover a failed RSSL connection. This controls how often RFA will attempt to recover a failed connection, after it has been established. This is only used after all servers in the serverList have been attempted.

Q: Is the connectionTimeout setting for the total time for the connection (login, directory...) or is it just for the login ?

The connectionTimeout setting is strictly to establish a connection to the server. The login and directory are not included in this time.

Hi @Wasin

Could you share how you reproduced the issue of the locked Thread?

Regards,

Mangesh

Hi @mangesh

I cannot replicate the locked thread issue. I can replicate only the scenario that the Provider (RFA Java StarterProvider_Interactive example) does not send the DIRECTORY Refresh message to the consumer.

I set the RFA Java StarterConsumer example connects to StarterProvider_Interactive example, then modify StarterProvider_Interactive's ProviderClientSession.java to not send the DIRECTORY Refresh message back to the StarterConsumer as following code:

protected void processOMMSolicitedItemEvent(OMMSolicitedItemEvent event){
   ...
    case RDMMsgTypes.DIRECTORY:
    // Reuters defined domain message model - DIRECTORY
    //For AHS_13227 test not sends DIRECTORY response to consumer
    //processDirectoryRequest(event);

When the StarterConsumer connects to the StarterProvider_Interactive, it keeps waiting for the DIRECTORY Refresh message forever, so I assume that there is no directory request timeout. The API also sends the STATUS_RESP "Waiting for service <service>. Item recovery in progress..." to the application because it does not receive a service information from the DIRECTORY Refresh message.

Please note that the API will not failover to the next Provider because the API and the StarterProvider_Interactive are still "connected".

Hi @mangesh

Sorry for my mistake. If the application manual send directory request to the ADS, , RFA Java times out at 45 seconds. RFA will close the request and send a status message to the application.

The StarterConsumer example does not make a Directory request, therefore the application will not receive any status message.