Hello,
I will upload the FTS log file here, as log files older than 5 days can no longer be viewed in the FTS Web Monitoring service.
The FTS log lines show a 15 minute timeout, not a one minute.
Something else mentioned by@wyang007 ... I don't think the statement about checksum and Performance Marker updates is correct. FTS receives Performance Markers during the transfer part, but not for the checksum. The checksum is a _request-and-wait_ operation.
FTS (in fact, this is all done at the Gfal2 level) requests the checksum to be computed at the end of the transfer part. The checksum computation is included in the _copy(..)_ operation. FTS decides the timeout for this according to the file size. In our case:
```
INFO Tue, 12 Jul 2022 10:12:08 +0200; Timeout set to: 7049
```
All other HTTP operations have absurdly long timeouts, so we never hit an operation timeout. The 15 minute timeout we see here comes from `libneon` (HTTP library employed by Davix).
I am curious if you are able to reproduce the issue with Davix and/or Gfal2:
```
$davix-http -X HEAD "Want-Digest: adler32" -H "Authorization: Bearer ${TOKEN}" <surl>
```
or
```
$ gfal-copy -vvv --log-file=gfal2.log --checksum-mode target --checksum adler32:<checksum> <src> <dst>
```
[2022-07-12-0829__cmsxrootd.hep.wisc.edu__xrootd.phy.bris.ac.uk__3394306095__5055e2c2-01ba-11ed-845d-fa163eddde58.log](https://github.com/xrootd/xrootd/files/9143390/2022-07-12-0829__cmsxrootd.hep.wisc.edu__xrootd.phy.bris.ac.uk__3394306095__5055e2c2-01ba-11ed-845d-fa163eddde58.log)
--
Reply to this email directly or view it on GitHub:
https://github.com/xrootd/xrootd/issues/1736#issuecomment-1189377653
You are receiving this because you commented.
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
