question

Upvotes
Accepted
LtDoolittle6 avatar image
301 ●6 ●17 ●27

RFA ServicGroup and ServerList question

My client found RFA error when there are incident on infra component. They use serverList parameter to configured two server in the list and use service group to subscribe data. We expect RFA switching to the next one in the list but it’s not. Application get following error instead and it stop receiving data.

2017 Jun 14 15:47:03.945 ST GMT+07:00 3AF0 31C8539 TRACE <- Received MMT_LOGIN Status - Login Accepted

streamState : Open

dataState: Ok

statusCode: None

statusText: RequestCompleted.

2017 Jun 14 15:47:03.972 ST GMT+07:00 3AF0 31C8596 TRACE <- Received MMT_MARKET_PRICE Status EUR=

serviceName : SG1

symbolName: EUR=

streamState : ClosedRecover

dataState: Suspect

statusCode: None

statusText: <SG1> Source cannot provide this QoS and capability.

And below is RFA configuration from the RFA subscriber.

\Connections\RSSL\connectionType = "RSSL"

\Connections\RSSL\connectionRetryInterval = 15000

\Connections\RSSL\serverList = "trep01:14007 trep08:14008"

\Connections\RSSL\serviceList= "S1"

\ServiceGroups\SG1\serviceList= "S1"

\Services\S1\feedName= "IDN_RDF"

\Sessions\Session1\connectionList = "RSSL"

\Sessions\Session1\ServiceGroupList = "SG1"

\Sessions\Session1\waitTimeout = 15000

From RSSL trace, it looks like the next server provide Delayed QOS but the first one is Real Time. That why we cannot replicate the issue in our test environment. Do you have any way to configure RFA to works on this scenario?

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

1 Answer

Upvotes
Accepted
moragodkrit.chumsri_1 avatar image
7.6k ●15 ●6 ●9

From the status text, you do not receive any update because item stream already been closed(ClsedRecover).

Based on initial information you provided, RFA does not fail over to the next server because the next server does not provide the same QOS and capability like the first one. Basically RFA will get directory info from directory message and in this case it does not match with the first one.

I can replicate the message when testing your configuration with two instance of Provider_Interactive example from RFA C++ examples folder. For the first instance I set QOS Rate=RealTime Timeliness=TickbyTick . The second one I modified the application's config to send service DIRECT_FEED with QOS Rate=Delayed, Timeliness=30. Next step I just run StarterConsumer with your configuration and get same status text when shutdown the Provider. It can’t switch to next one in serverList.

A far as I understand this behavior can be changed by setting the QOS streamProperty to dynamicStream in the OMM item request message. In order to set the QOS streamProperty in the Item Request message, you have to add the following codes when you set the request message.

QualityOfServiceRequestqosReq;
qosReq.setStreamProperty(QualityOfServiceRequest::StreamPropertyEnum::DynamicStream);

reqMsg.setRequestedQualityOfService(qosReq);

I have modifed StarterConsumer to add above codes when it send item request and then re-test with the Provider example. This time it can switch to next one as expect. Please add the codes to your application and test it with the server. If the problem persists, please turn on RSSL tracing log and open a new support ticket to API Support directly.

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