Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you are subscribed to this thread.
@adriansev : the STREAMTIMEOUT is definitely what you need, recall that metalinks are treated as virtual redirectors, this means that if there is an error recovery it would happen directly at the metalling level as we have this data already at hand. You might ask what does it even mean to do error recovery, well, it means to resend a request that failed (e.g. due to STREAMTIMEOUT) to a different server, in our case the next server in the metalink file (which is exactly what you want).
I do realise that the naming convention is, well let's say bit misleading, but unfortunately there's no way we can change it now.
For more detailed explanation on how the timeouts of XRootD client work please visit:
https://xrootd.slac.stanford.edu/doc/xrdcl-docs/www/xrdcldocs.html#x1-580004.3.6
also, i would argue against non-recoverability: given that i (can) have multiple replica in a metafile, why should be
unrecoverable? just fail on the particular request, move to next replica if any, then respect the -retry parameter if any ..
The REQUESTTIMEOUT is non-recoverable by policy, the goal is to have an API that allows the user to tell here's an operation timeout if it elapses please do abort (it should have been probably called operation t/o but the times when this has been decided predates me ;-)
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you are subscribed to this thread.
Use REPLY-ALL to reply to list
To unsubscribe from the XROOTD-DEV list, click the following link:
https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-DEV&A=1