What exactly does this “read timeout” mean?

Question

I have a daily data extraction process where I retrieve data for about 30 curve IDs for the last 7 days all in a single request.

At first, it worked without any problems, but last week, on 2 out of 7 days, I was unable to retrieve the data due to a read timeout.

What exactly does this “read timeout” mean? From what I’ve read, it has nothing to do with the amount of data.

How can I ensure that this timeout doesn’t occur?

Batch curve values: transport error: HTTPSConnectionPool(host='sprod1.rdms.refinitiv.com', port=443): Read timed out. (read timeout=60)

Jirapongse · Answer

@FHaller

Based on the URL, it appears that this endpoint belongs to the RDMS product and is not related to the LSEG Data Library for Python. Could you please confirm whether my understanding is correct?

If you are using the requests module in Python, you can try to increase the HTTP timeout value.

ujjawal_khandelwal · Answer

Hi @FHaller, Thank you for your question! The error message indicates: Read timed out. (read timeout=60) The read timeout=60 confirms that your client is currently set to wait 60 seconds for a response before giving up. A read timeout is not triggered by the size of the data being returned - it's triggered when the server takes longer than the configured threshold to respond. The connection is established successfully, but the server-side processing (computing/retrieving 30 curves × 7 days) occasionally exceeds that window on busy days. The fix is straightforward - increase the timeout in your lseg-data.config.json: You can read here: LSEG's Refinitiv Data Library for Python and its Configuration Process { "http": { "request-timeout": 300 }, "logs": { ... } ... } 300 seconds is the recommended maximum, aligned with the server-side limit. This should prevent the timeout. As an additional safeguard, consider chunking your requests rather than sending all 30 curve IDs for 7 days in a single call. Smaller batches reduce per-request processing time on the server and make your pipeline more resilient - if one batch fails, you only need to retry that slice rather than the entire request. We cover this pattern in detail in our article series: LSEG Data Library - Patterns and Features - Vol. 3: Calls That Survives Scale. Please let me know if you found this helpful. Thank you : )

EXPLORE OUR SITES