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
Best Answer
-
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.
0
Answers
-
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.
0 -
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 Sharma0 -
@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
0 -
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.
0 -
Thank you @Jirapongse .
0
Categories
- All Categories
- 3 Polls
- 6 AHS
- 36 Alpha
- 166 App Studio
- 6 Block Chain
- 4 Bot Platform
- 18 Connected Risk APIs
- 47 Data Fusion
- 34 Data Model Discovery
- 685 Datastream
- 1.4K DSS
- 615 Eikon COM
- 5.2K Eikon Data APIs
- 10 Electronic Trading
- Generic FIX
- 7 Local Bank Node API
- 3 Trading API
- 2.9K Elektron
- 1.4K EMA
- 252 ETA
- 556 WebSocket API
- 38 FX Venues
- 14 FX Market Data
- 1 FX Post Trade
- 1 FX Trading - Matching
- 12 FX Trading – RFQ Maker
- 5 Intelligent Tagging
- 2 Legal One
- 23 Messenger Bot
- 3 Messenger Side by Side
- 9 ONESOURCE
- 7 Indirect Tax
- 60 Open Calais
- 275 Open PermID
- 44 Entity Search
- 2 Org ID
- 1 PAM
- PAM - Logging
- 6 Product Insight
- Project Tracking
- ProView
- ProView Internal
- 22 RDMS
- 1.9K Refinitiv Data Platform
- 652 Refinitiv Data Platform Libraries
- 4 LSEG Due Diligence
- LSEG Due Diligence Portal API
- 4 Refinitiv Due Dilligence Centre
- Rose's Space
- 1.2K Screening
- 18 Qual-ID API
- 13 Screening Deployed
- 23 Screening Online
- 12 World-Check Customer Risk Screener
- 1K World-Check One
- 46 World-Check One Zero Footprint
- 45 Side by Side Integration API
- 2 Test Space
- 3 Thomson One Smart
- 10 TR Knowledge Graph
- 151 Transactions
- 143 REDI API
- 1.8K TREP APIs
- 4 CAT
- 27 DACS Station
- 121 Open DACS
- 1.1K RFA
- 104 UPA
- 193 TREP Infrastructure
- 228 TRKD
- 917 TRTH
- 5 Velocity Analytics
- 9 Wealth Management Web Services
- 90 Workspace SDK
- 11 Element Framework
- 5 Grid
- 18 World-Check Data File
- 1 Yield Book Analytics
- 46 中文论坛