 |
 |
@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 or view it on GitHub: https://github.com/xrootd/xrootd/issues/1597#issuecomment-1064081574 You are receiving this because you are subscribed to this thread. Message ID: <[log in to unmask]> ######################################################################## 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