Datascope select monitoring api respond-async wait time

Hi,

I am building a system to process hundreds of requests for many different users, for the Datascope select api for TickHistoryTimeAndSalesExtraction. My plan is to handle asynchronicity in the application by calling the monitor api (i.e. /RestApi/v1/Extractions/ExtractRawResult(ExtractionId='0x123456789')) every 30 seconds, until receiving a 200 response. To achieve that I am setting the "prefer" http header, with a value of "respond-async, wait=1". However, I am finding that the response always takes at least 30 seconds (unless the extraction is completed). This is a problem, as I do not want to keep hundreds of concurrent http connections open for the 30 seconds each.

Is this the expected behaviour for this api?


Note, I have found that the "respond-async, wait=1" works as I would expect for the initial "ExtractRaw" request.


Many Thanks

Best Answer

  • Jirapongse
    Answer ✓

    @david.p.newman

    Thank you for reaching out to us.

    I tested and found that for polling a location URL, the mininum value of wait time is 30 seconds.

    1715834477204.png

    If I set the wait time to less than 30 seconds, it will use 30 seconds.

    However, if I set the wait time to more than 30 seconds, it will use the value in the wait time.

    1715834752041.png


Answers

  • @Jirapongse Thanks for the reply. It's good to note that you are experiencing the same behaviour as me. Is this behaviour intentional? Do you know the reason for it? It seems unusual to me and limits the flexibility of the consumer. It means that my application now has to wait for a minimum of 30 when making the first monitoring request following an extraction request. Do you have any recommendations to mitigate this? Thanks.

  • @david.p.newman

    Please contact the DSS support team directly via MyRefinitiv to confirm this behavior.

    I found this statement in the Async Key Mechanism.

    Prefer: respond-async, wait=120 The default wait/poll time is 30 seconds. The API uses long polling, which means that it will respond either with the results, or with a 202 if the results could not be returned in 30 seconds. We do not recommend changing this value. Changing the value will not result in getting results more quickly. In fact, more frequent polling, by reducing the poll time, will incur an additional overhead and a slight reduction in the response time.


  • I am also interested in this! We use a serverless architecture and would prefer not to pay for our Cloud Functions or Lambdas to just wait on an API response!