*** RFA client does not automatically connect to the next ADS server ***

mangesh
mangesh Explorer

We have been using RFA 7.6 in production currently. What we have observed in our test is if the connection to the first ADS in the serverList parameter is lost (disconnected by ADS as an example), RFA will automatically attempt connection to the second server mentioned in the serverList parameter.
However, we do not see this when we test with RFA 8 (currently RFA 8.0.1.E3). When the ADS disconnects the RFA client, no attempt is made to connect to the second server in serverList. Has anyone observed something similar? Was there any other parameter introduced RFA 8.x onwards that needs to be set explicitly for automatic failover?

Tagged:

Best Answer

  • Hi @mangesh,

    I've just quickly tested the scenario given. It seems like RFA can switch to the second server given in the serverList as you can see in the log below.

    Before moving to my log information, I would like to suggest two useful parameters for tracking a connection:

    • mountTrace: true
    • logFileName: <a full file name or just a file name or 'console'>

    Note that these parameters are under a connection node.

    image

    You should try them, and reproduce this problem again. RFA will log more useful information to identify the cause of this issue.

    According to my test, 192.168.27.46 is the first server, and 192.168.27.48 is the second server.

    *****************************************************************************
    * Begin RFA Java StarterConsumer Program *
    *****************************************************************************
    *myNamespace.Connections.myConnection.mountTrace : true
    *myNamespace.Connections.myConnection.serverList : 192.168.27.46,192.168.27.48
    *myNamespace.Connections.myConnection.logFileName : console
    *myNamespace.Connections.myConnection.portNumber : 14002
    *myNamespace.Connections.myConnection.connectionType : RSSL
    *myNamespace.Connections.myConnection.ipcTraceFlags : 3
    *myNamespace.Sessions.mySession.connectionList : myConnection


    RFA Version: 8.0.1.E3.all.rrg
    field dictionary read from RDMFieldDictionary file
    enum dictionary read from enumtype.def file
    LoginClient: Sending login request...
    Mar 01, 2017 11:07:14 AM com.reuters.ipc.TraceLogger traceData
    FINER:
    Thread: myNamespace::mySession Session EventQueueGroup
    Connection 0
    RSSL Transport attempt to connect to 192.168.27.46:14002


    Mar 01, 2017 11:07:14 AM com.reuters.ipc.TraceLogger traceData
    FINER:
    Thread: myNamespace::mySession Session EventQueueGroup
    Connection 0
    RSSL Transport connected to 192.168.27.46:14002


    Mar 01, 2017 11:07:14 AM com.reuters.rfa.internal.connection.rssl.RSSLClientConnection processTransportConnected
    INFO: com.reuters.rfa.connection.rssl.myNamespace.myConnection
    Connection[myNamespace::myConnection]: Requested version 14:1, Connected version 14:0


    Mar 01, 2017 11:07:14 AM com.reuters.rfa.internal.connection.rssl.RSSLClientConnection processTransportConnected
    INFO: com.reuters.rfa.connection.rssl.myNamespace.myConnection
    Connection[myNamespace::myConnection] = (14:0)


    Mar 01, 2017 11:07:14 AM com.reuters.rfa.internal.connection.rssl.RSSLLoginHandler sendLoginReqMsg
    INFO: com.reuters.rfa.connection.rssl.myNamespace.myConnection
    Sending Login Request to 192.168.27.46:14002


    Mar 01, 2017 11:07:14 AM com.reuters.ipc.TraceLogger traceDataSize
    FINER:
    Thread: myNamespace::mySession Session EventQueueGroup
    Connection 0
    RSSL Client Message
    SEND: 145


    Mar 01, 2017 11:07:14 AM com.reuters.ipc.TraceLogger traceDataSize
    FINER:
    Thread: myNamespace::mySession Session EventQueueGroup
    Connection 0
    RSSL Client Message
    RECEIVE: 361


    Mar 01, 2017 11:07:14 AM com.reuters.rfa.internal.connection.rssl.RSSLLoginHandler processMsg
    INFO: com.reuters.rfa.connection.rssl.myNamespace.myConnection
    Login received from 192.168.27.46:14002


    Mar 01, 2017 11:07:14 AM com.reuters.ipc.TraceLogger traceDataSize
    FINER:
    Thread: myNamespace::mySession Session EventQueueGroup
    Connection 0
    RSSL Client Message
    SEND: 19


    Mar 01, 2017 11:07:14 AM com.reuters.rfa.internal.connection.rssl.RSSLLoginHandler makeDirReq
    INFO: com.reuters.rfa.connection.rssl.myNamespace.myConnection
    Login received from 192.168.27.46:14002


    Mar 01, 2017 11:07:14 AM com.reuters.ipc.TraceLogger traceDataSize
    FINER:
    Thread: myNamespace::mySession Session EventQueueGroup
    Connection 0
    RSSL Client Message
    RECEIVE: 1158

    After that, we cut the current connection established to 192.168.27.46, which resulted RFA switched to the secondary server specified in the serverList parameter.

    Mar 01, 2017 11:07:25 AM com.reuters.ipc.TraceLogger traceData
    FINER:
    Thread: myNamespace::mySession Session EventQueueGroup
    Connection 0
    RSSL Connection failed for 192.168.27.46: An existing connection was forcibly closed by the remote host


    Mar 01, 2017 11:07:25 AM com.reuters.ipc.TraceLogger traceData
    FINER:
    Thread: myNamespace::mySession Session EventQueueGroup
    Connection 0
    RSSL Transport attempt to connect to 192.168.27.48:14002


    Mar 01, 2017 11:07:25 AM com.reuters.ipc.TraceLogger traceData
    FINER:
    Thread: myNamespace::mySession Session EventQueueGroup
    Connection 0
    RSSL Transport connected to 192.168.27.48:14002


    Mar 01, 2017 11:07:25 AM com.reuters.rfa.internal.connection.rssl.RSSLClientConnection processTransportConnected
    INFO: com.reuters.rfa.connection.rssl.myNamespace.myConnection
    Connection[myNamespace::myConnection]: Requested version 14:1, Connected version 14:0


    Mar 01, 2017 11:07:25 AM com.reuters.rfa.internal.connection.rssl.RSSLClientConnection processTransportConnected
    INFO: com.reuters.rfa.connection.rssl.myNamespace.myConnection
    Connection[myNamespace::myConnection] = (14:0)


    Mar 01, 2017 11:07:25 AM com.reuters.rfa.internal.connection.rssl.RSSLLoginHandler sendLoginReqMsg
    INFO: com.reuters.rfa.connection.rssl.myNamespace.myConnection
    Sending Login Request to 192.168.27.48:14002


    Mar 01, 2017 11:07:25 AM com.reuters.ipc.TraceLogger traceDataSize
    FINER:
    Thread: myNamespace::mySession Session EventQueueGroup
    Connection 0
    RSSL Client Message
    SEND: 145


    Mar 01, 2017 11:07:25 AM com.reuters.ipc.TraceLogger traceDataSize
    FINER:
    Thread: myNamespace::mySession Session EventQueueGroup
    Connection 0
    RSSL Client Message
    RECEIVE: 358


    Mar 01, 2017 11:07:25 AM com.reuters.rfa.internal.connection.rssl.RSSLLoginHandler processMsg
    INFO: com.reuters.rfa.connection.rssl.myNamespace.myConnection
    Login received from 192.168.27.48:14002


    Mar 01, 2017 11:07:25 AM com.reuters.ipc.TraceLogger traceDataSize
    FINER:
    Thread: myNamespace::mySession Session EventQueueGroup
    Connection 0
    RSSL Client Message
    SEND: 19


    Mar 01, 2017 11:07:25 AM com.reuters.rfa.internal.connection.rssl.RSSLLoginHandler makeDirReq
    INFO: com.reuters.rfa.connection.rssl.myNamespace.myConnection
    Login received from 192.168.27.48:14002


    Mar 01, 2017 11:07:25 AM com.reuters.ipc.TraceLogger traceDataSize
    FINER:
    Thread: myNamespace::mySession Session EventQueueGroup
    Connection 0
    RSSL Client Message
    RECEIVE: 1438

    In the failure scenario, Assuming that the secondary server 192.168.27.45 (in the serverList parameter) is down, RFA will convey that the result of the attempt to connect to this server will be .timeout', and RFA will fail-over to the next server or back to the first server in the serverList.

    *****************************************************************************
    * Begin RFA Java StarterConsumer Program *
    *****************************************************************************
    *myNamespace.Connections.myConnection.mountTrace : true
    *myNamespace.Connections.myConnection.serverList : 192.168.27.46,192.168.27.45
    .
    .
    .
    Mar 01, 2017 11:10:41 AM com.reuters.ipc.TraceLogger traceData
    FINER:
    Thread: myNamespace::mySession Session EventQueueGroup
    Connection 0
    RSSL Connection failed for 192.168.27.46: An existing connection was forcibly closed by the remote host


    Mar 01, 2017 11:10:41 AM com.reuters.ipc.TraceLogger traceData
    FINER:
    Thread: myNamespace::mySession Session EventQueueGroup
    Connection 0
    RSSL Transport attempt to connect to 192.168.27.45:14002


    Mar 01, 2017 11:10:51 AM com.reuters.ipc.TraceLogger traceData
    FINER:
    Thread: myNamespace::mySession Session EventQueueGroup
    Connection 0
    RSSL Connection failed for 192.168.27.45: Connect attempt timeout


    Mar 01, 2017 11:11:06 AM com.reuters.ipc.TraceLogger traceData
    FINER:
    Thread: myNamespace::mySession Session EventQueueGroup
    Connection 0
    RSSL Transport attempt to connect to 192.168.27.46:14002


    Mar 01, 2017 11:11:06 AM com.reuters.ipc.TraceLogger traceData
    FINER:
    Thread: myNamespace::mySession Session EventQueueGroup
    Connection 0
    RSSL Transport connected to 192.168.27.46:14002

    Hope this helps.

Answers

  • mangesh
    mangesh Explorer

    Hi Nipat,

    One thing that I have recently noticed is that if I keep requesting timely service Directory updates then the Failover does not work. (test done with RFA 8.0.1.E1) We have a timed request for Source Directory request message. This prevents failover from Primary to Secondary ADS.

    OMMMsg directoryReqMsg = _pool.acquireMsg();
    directoryReqMsg.setMsgType(OMMMsg.MsgType.NONSTREAMING_REQ);
    directoryReqMsg.setMsgModelType(RDMMsgTypes.DIRECTORY);
    OMMAttribInfo attribInfo = _pool.acquireAttribInfo();
    attribInfo.setFilter( RDMService.Filter.INFO | RDMService.Filter.STATE );
    directoryReqMsg.setAttribInfo( attribInfo );

    OMMItemIntSpec ommItemIntSpec = new OMMItemIntSpec();
    ommItemIntSpec.setMsg(directoryReqMsg);