Regarding rsslReadEx return code
Needed some help with using the ETA library to connect to servers. We were facing issues with connection reset by peer and as per lseg we were not consuming faster enough. I believe I found the issue in the code were we are not consuming from the library properly. However with the change am not seeing the behavior as explained in the ETA specification. We are currently using rsslReadEx instead of rsslRead (however I believe other than the exception of having two extra parameter they both are the same. Please correct me if wrong).
As per below snippet from document, I see we are always getting retCode as 1 and so our process is now stuck at processing the updates from rsslReadEx continuously (we never get this RSSl_RET_SUCCESS).
From our logs as you can see below rsslRet (=retcode above) is always 1 which doesn’t explain what rsslCode it is from rsslRetCodes.h file (I see enums for all except 1). And as you can see the bytesRead and bytesDecompressed are both 0s. So I believe this buffer length (returned from rsslReadEx) is the data from the rssl library buffers? So is it expected to continuously receive this value of 1 for rsslRet code? Appreciate your help with this. Thanks a lot.
Best Answers
-
Thank you for reaching out to us.
The document indicates that if the return code is more than 0, this indicates that the rsslReadEx call was successful and there are remaining bytes in the input buffer. The I/O notification mechanism will not notify the user of these bytes. The function should be called again to ensure that the remaining bytes are processed.
be updated.Yes, the buffer length (returned from rsslReadEx) is the data from the RSSL library buffers. The contents are only valid until the next call to rsslReadEx.
I think the buffers returned in the blue box are from the 5027 decompressed bytes. According to the output, this decompressed bytes (5027) contains 21 messages and the rsslReadEx returns a buffer that contains each message for each call.
You can refer to the Consumer example that demonstrates how to use this function.
1 -
Are you decoding and processing the data on the same thread that calls the rsslReadEx? You may need to remove the decoding or processing logic to other threads.
You may count the number of update messages that the application can process per second.
Calling the rsslReadEx method from multiple threads can result in data being processed or returned out of order.
0
Answers
-
Thanks a lot for the response. Is there a way to find if we are still lagging in consuming updates from the rsslReadEx and if the input buffers are not getting consumed faster? Also is it possible for multiple threads to call rsslReadEx in parallel so we don't end up having the buffers fill up and causing disconnection. Appreciate your help. Thanks a lot.
0 -
Thanks again @Jirapongse . We are running all the rsslDecode* of the received data from rsslReadEx on the same thread. So should we move this rssl decoding to a different thread? However our specific logic for this decoded data runs on a different thread (binded to a different CPU). So currently I was able to improve some performance issues and not seeing this queuing of messages anymore. However it looks like we are running the rsslReadEx on a blocking mode (RsslConnectOptions::blocking set to RSSL_TRUE) and so now the rsslReadEx takes some time (<1ms) to return the data. And I see the CPU core assigned to this processing thread goes into sleep state most of the time (I believe rsslReadEx is waiting for the kernel to give the packet from network). Two questions.
1. Is there a way to run rsslReadEx in a busy wait loop so it doesn't go into a sleep (interruptible sleep state). Its already running on an isolated CPU core and can consume the core to its full extent. Currently I see the core is mostly idle (although we aren't queuing any data on TCP queues and consuming it immediately). Only worried if this is adding to any latency on the received data.
2. We use onload library to bypass kernel and get the packets quicker. Is there a way to enable onload on ETA sockets?0 -
The library can run with blocking and non-blocking mode. You can refer to the \Cpp-C\Eta\Applications\PerfTools\ConsPerf sample that demonstrates best practice and coding for performance.
You can also refer to the OPEN SOURCE PERFORMANCE TOOLS GUIDE in the package.
To process the raw packet, you need to know our RSSL specification which is our proprietary standard. Therefore, we don't support this kind of usage.
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
- 651 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 中文论坛