We have used rdp.StreamingPrices and registered many RICs, at specific time, if we can get details how many pending callbacks in cache of StreamingPrices, it will give us idea how much liquid market and how many RICs / FIDs we should register for an application. callbacks remain pending because we might consume slowly because of calculations than market ticks received.
1
●0 ●1 ●1
RDP need details of pending callbacks from rdp.StreamingPrices
Hi,
Thank you for your participation in the forum. Is the reply below satisfactory in resolving your query? If yes, please click the 'Accept' text next to the reply.
This will guide all community members who have a similar question. Otherwise please post again offering further insight into your question.
Thanks,
AHS
Please be informed that a reply has been verified as correct in answering the question, and has been marked as such.
Thanks,
AHS
7.6k
●15 ●6 ●9
I'm not quite sure about the issue you are facing. It would be great if you can provide sample codes with more info or sample about the issue.
Anyway, from the initial details, it sounds like you using the implementation like the example 2.3.1 - Content - StreamingPrices - With all events.ipynb from https://github.com/Refinitiv-API-Samples/Example.RDPLibrary.Python?
-Not sure how many RICs you are using?
It seems like you found a slow consumer when you add more RIC to the codes, and it seems to occur because you add some calculation inside the callback function. Does the implementation seem to block the app to process the next message?
17.3k
●82 ●39 ●63
Can you elaborate on the details you were expecting? The underlying libraries use the network/IPC queues to populate a cache and to optionally present the data within user-defined callbacks.
Are you using StreamingPrices with your own callback? If so, and you are finding that your callback post-processing is affecting the consumption of data, I would suggest launching the processing within a separate processing thread or a background task to ensure you return from your callback immediately.
Alternatively, I would suggest not to define a user callback but instead rely on the internal cache to feed your pricing needs. You can snap data from your cache at regular intervals.
