question

Upvotes
Accepted
5 2 2 6

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

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?

treprfarfa-api
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.

Upvotes
Accepted
1.9k 6 9 16

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.

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.


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.

Upvotes
5 2 2 6

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);

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.

Click below to post an Idea Post Idea