Slow processing of on-demand PriceHistory requests (up to 7 hours)
Hi Forum!
The forum looks very active, looking forward to learn from you guys!
We are loading terms and conditions as well as price time series with 6 fields for around 5000 instruments with the on-demand TermsAndConditions and PriceHistory requests. We try to adhere to the limit of 50 concurrent PriceHistory requests, as laid out in the manual. However, often our PriceHistory requests end up being stuck in the queue at Datascope, taking several hours to complete (up to 7 hours). In the notes we can see the actual processing times of the PriceHistory requests, which are in the range of seconds.
Does anybody have an idea why our requests get stuck in the queue at Datascope, and can help us in answering our questions:
- Why do our requests get stuck in the queue?
- How does the scheduling algorithm of Datascope work?
- How can we optimize our requests such that they won't get stuck in the queue?
Best Answer
-
Hello @quantE,
These are excellent questions.
I am afraid there is no all-encompassing answers that I can think of.
I also understand that this happens for some, few, of the requests that you issue.
Please note that if you submit full 50 allowed Price History requests at a time, and some may be large, only 2 are taken up for processing, while the rest 48 remain in the queue till the first 2 complete processing, please see more info in DSS Best Practices section Extraction Limits for more details on processing. I.e. if you have one or two request that are very large, they may hold up the remaining 48 on queue till completed. So I think there is a chance your requests may be queued long, rather then processed long.
Please try to analyze your submission timeline and see if you can better understand the pattern to those requests that take long?
If not, are you able to test the same PriceHistory requests, submitting 2 at a time, till completed and see if this takes care of the timing discrepancies?
If not, then for the specific request that has taken 7 hours, I would suggest, as a customer, to investigate this specific request. When this happens, to collect full info on when it was submitted, when the status changed to completed, on your side, the jobId, extraction notes if available, and open a support case with with DSS product support with Refinitivi Helpdesk Online to investigate the specific case.
Please let us know if this information helps you proceed.
0
Categories
- All Categories
- 6 AHS
- 36 Alpha
- 166 App Studio
- 6 Block Chain
- 4 Bot Platform
- 18 Connected Risk APIs
- 47 Data Fusion
- 34 Data Model Discovery
- 683 Datastream
- 1.4K DSS
- 613 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
- 248 ETA
- 552 WebSocket API
- 37 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
- 627 Refinitiv Data Platform Libraries
- 5 LSEG Due Diligence
- 1 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
- 26 DACS Station
- 121 Open DACS
- 1.1K RFA
- 104 UPA
- 191 TREP Infrastructure
- 228 TRKD
- 915 TRTH
- 5 Velocity Analytics
- 9 Wealth Management Web Services
- 84 Workspace SDK
- 11 Element Framework
- 5 Grid
- 18 World-Check Data File
- 1 Yield Book Analytics
- 46 中文论坛