You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It wouldn't work for some failures, and that's the hard part: deciding when retrying is likely to work and when it's doomed and you're just extending the time needed before getting a useful error message to the user.
Here's the original #1217 (comment), which has some notes about how it could be implemented.
If this were to be done in Uproot, we'd have to dynamically adjust the request size and resubmit when we see such an error, and have some reasonable give-up policy after a specified number of retries to keep it from spiraling out of control. And if the OSError came from a local file, rather than XRootD, it's not retryable (if an open local file suddenly can't be read, someone must have unplugged the disk or something).
Possibly the smallest sections that would need to be retried are:
Maybe it's possible to retry only the _ranges_or_baskets_to_arrays call, but I'm not sure if there would be a counting problem if the arrays dict and ranges_or_baskets list are not reinitialized after a partial failure. (These are notes for implementation.) If the number of items in the arrays dict is wrong, the code will hang in this loop, rather than raise an error!
There would also need to be a way to change the granularity of the XRootD request while still requesting all the data the user wants. The Source.chunks method doesn't have a way to express that, but maybe the coalesce algorithm does? Unfortunately, coalesce arguments are specified per-FSSpecSource object, but maybe each retry could be a new, more finely granular FSSpecSource? (We don't know if another thread is using the same FSSpecSource object; we can't change it in place.)
It wouldn't work for some failures, and that's the hard part: deciding when retrying is likely to work and when it's doomed and you're just extending the time needed before getting a useful error message to the user.
Here's the original #1217 (comment), which has some notes about how it could be implemented.
If this were to be done in Uproot, we'd have to dynamically adjust the request size and resubmit when we see such an error, and have some reasonable give-up policy after a specified number of retries to keep it from spiraling out of control. And if the OSError came from a local file, rather than XRootD, it's not retryable (if an open local file suddenly can't be read, someone must have unplugged the disk or something).
Possibly the smallest sections that would need to be retried are:
in
HasBranches.arrays
:uproot5/src/uproot/behaviors/TBranch.py
Lines 797 to 835 in 13087b0
in
HasBranches.iterate
:uproot5/src/uproot/behaviors/TBranch.py
Lines 1034 to 1072 in 13087b0
in
Branch.array
:uproot5/src/uproot/behaviors/TBranch.py
Lines 1787 to 1831 in 13087b0
Maybe it's possible to retry only the
_ranges_or_baskets_to_arrays
call, but I'm not sure if there would be a counting problem if thearrays
dict andranges_or_baskets
list are not reinitialized after a partial failure. (These are notes for implementation.) If the number of items in thearrays
dict is wrong, the code will hang in this loop, rather than raise an error!There would also need to be a way to change the granularity of the XRootD request while still requesting all the data the user wants. The Source.chunks method doesn't have a way to express that, but maybe the coalesce algorithm does? Unfortunately, coalesce arguments are specified per-FSSpecSource object, but maybe each retry could be a new, more finely granular
FSSpecSource
? (We don't know if another thread is using the sameFSSpecSource
object; we can't change it in place.)Originally posted by @jpivarski in #1217 (comment)
The text was updated successfully, but these errors were encountered: