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.

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

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.