SFC api going into loop

After a disconnect from the reuters server, the SFC api went
into an infinite loop and I can see the following SSL logs repeatedly in the
application log file.

sslPostEvent(SSL_ET_IMAGE_REQ) failed on channel 0.
Reason: Wed Jan 10 00:42:35 2018 file = ssl/edapi.c, line = 7815, Channel = 0
sslSnkOpen: System Error: Event Posting failed for Event 35. Item ESE Service
hEDD

Could you please help in answering the following query:

1) What does the SSL logs (highlighted above) means and
why did the API went into the loop.

2) What can be done to detect and recover from this state

Find more posts tagged with

trep

elektron

sfc

refinitiv-realtime

Accepted answers

Jirapongse

RTRSSLConnection class can be used to get processConnected and processNotConnected callbacks.

You can get RTRSSLConnection by creating it and then passing it to RTRSSLRTRecordService. Then call RTRSSLConnection::connect() method.

RTRSSLConnection* connection = new RTRSSLConnection(appId, "sslConnection");
service = new RTRSSLRTRecordService(appId, servicename, *connection);
connection->connect();

Otherwise, you can get it from the

RTRSSLConnection *RTRSSLRTRecordService::connection() method.

After getting RTRSSLConnection, you can call RTRMDConnection::addClient(RTRMDConnectionClient &c) method to register an object that implements RTRMDConnectionClient to receive connection callbacks.

class ConnectionClient : public RTRMDConnectionClient
{
...
public:
	ConnectionClient();
	~ConnectionClient(void);
	void processConnected(RTRMDConnection &);
	void processNotConnected(RTRMDConnection &);


};
...

ConnectionClient* connClient = new ConnectionClient();
connection->addClient(*connClient);

In processNotConnected, the application can unsubscribe records by calling RTRRTRecord::dropClient() method. Then, in processConnected, the application can resubscribe.

All comments

Jirapongse

1. The message indicates SFC is unable to send an item request because the channel may be disconnected. You will see this message for each item request sent by SFC

2. Typically, after disconnection, SFC will perform the recovery by re-connecting to the server and then re-subscribing to all items in the watchlist

If you see this behavior (disconnection and re-connection) repeatedly, you may need to verify the server's log for the reason of disconnection. One common scenario which can causes this behavior is that the server disconnects the channel due to buffer overflow. This indicates that the application is a slow consumer.

mktdata

Hi,

Appreciate your response here.
You are correct about the channel
disconnection. But, from the logs i can see that we were reconnected,
but SFC kept sending these re-subscription requests. This effectively
resulted in an infinite loop. So i would like to be able to handle this
at the application level.
So is there a way to detect (like a callback) this disconnection at application level and stop the re-subscription process

Thanks,
Varun Sharma

Jirapongse

RTRSSLConnection class can be used to get processConnected and processNotConnected callbacks.

You can get RTRSSLConnection by creating it and then passing it to RTRSSLRTRecordService. Then call RTRSSLConnection::connect() method.

RTRSSLConnection* connection = new RTRSSLConnection(appId, "sslConnection");
service = new RTRSSLRTRecordService(appId, servicename, *connection);
connection->connect();

Otherwise, you can get it from the

RTRSSLConnection *RTRSSLRTRecordService::connection() method.

class ConnectionClient : public RTRMDConnectionClient
{
...
public:
	ConnectionClient();
	~ConnectionClient(void);
	void processConnected(RTRMDConnection &);
	void processNotConnected(RTRMDConnection &);


};
...

ConnectionClient* connClient = new ConnectionClient();
connection->addClient(*connClient);

In processNotConnected, the application can unsubscribe records by calling RTRRTRecord::dropClient() method. Then, in processConnected, the application can resubscribe.

mktdata

@Jirapongse This phenomenon is explained as Thrashing in 5.4.4 Request Queuing and Timing Chapter.

Can you help us how can we calculate the request queue parameters as default values dont seem to be working for us. documentation shows only default values

Jirapongse

@mktdata

If the root cause of this problem is a slow consumer. Changing the request queue parameters may not help because the application will be disconnected again when the update rate reaches to the point that the application is unable to handle.

First, you need to determine the performance of the application by measuring the update rate that the application can handle per second and then comparing to the real update rate per second of all subscribed items.

If the real update rate of all subscribed items is higher than the update rate that the application can handle, you need to improve the performance of the application.

SFC C++ is a legacy API and it is a single thread so it might not be able to handle subscribed items with high update rate.

The short-term solution is running multiple instances of the application and distributing RICs across those instances.

The long-term solution is migrating the application to use Elektron SDKs or RFA APIs.

mktdata

Thank you @Jirapongse .

EXPLORE OUR SITES