Hi @abh3,

To be honest, I think what I'm after is something a little higher-level: if a transfer fails (or succeeds with a warning) with dCache's embedded client then there is a similar behaviour with xrdcp. This is for two reasons:

1. It gives a clearer impression that the problem is with the endpoint, rather than dCache.
2. It gives a site (e.g., RAL) an easier way to test their endpoint (when trying to fix the problem).

However, I'm now wondering if we should simply adopt the xrdcp strategy in dCache's embedded client: ensure that we know the file's size and only request the outstanding data for the final read.

Currently the dCache embedded client always makes fixed size read requests and stops once it has received enough bytes. This should work, but it relies on the server correctly delivering fewer bytes than were requested in the final read request -- which is (apparently) problematic.

Perhaps there's an issue of making it easy for a site to test and diagnose problems with their endpoint (particularly if they are developing their own storage plugin). That might be addressed with some set of conformance tests that a site could run. One of those tests could try making repeated reads with a fixed (perhaps configurable) size and checking the server yields the expected number of bytes. More tests could be added when other problems surface.

I'll talk with Al and see how he feels about updating the dCache embedded client so it limits the size of the final request.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.

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