question

Upvotes
Accepted
148 2 3 10

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

elektronrefinitiv-realtimetrepsfc
icon clock
10 |1500

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

Hi,

Thank you for your participation in the forum.

Are any of the replies below satisfactory in resolving your query?

If yes please click the 'Accept' text next to the most appropriate reply. This will guide all community members who have a similar question.

Otherwise please post again offering further insight into your question.

Thanks,

AHS

Upvotes
Accepted
49.8k 124 44 62

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.

icon clock
10 |1500

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

Upvotes
49.8k 124 44 62

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.

icon clock
10 |1500

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

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.phuriphanvichai 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

Upvote
49.8k 124 44 62

@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.

icon clock
10 |1500

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.