-
Notifications
You must be signed in to change notification settings - Fork 36
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Introspect redirections for HTTP TPC xfers #101
Comments
Hello, This is a great proposal and it targets a problem we hit very often in FTS/Gfal2 transfers. Some theory Once the HTTP-TPC starts, the active party will continuously send transfer updates back to the initiating client, in this case Davix. These updates are called HTTP-TPC Performance Markers, and one such field is the Back to the problem std::string getTransferSourceHost() const;
std::string getTransferDestinationHost() const; After the transfer is done, they will return either the hostname or IP value, or empty, if no information is available. The active party is resolved by Davix, just before initiating the Here is an example of how FTS/Gfal2 will leverage this information:
All Davix changes have been implemented in commit 969b9a5. Cheers, |
To better debug failing HTTP-TPC transfers, it would be nice to expose to users of libdavix the hostname actually responsible for the transfer after redirection, if any.
I originally thought that adding a
getCurrentUri
analogous togetOriginalUri
to expose the protected_current
variable from BackendRequest would be sufficient to get things goingdavix/src/backend/BackendRequest.hpp
Line 178 in 23a591d
... but this is the wrong place to solve it. In
DavixCopyInternal::copy
, there is logic to work through the redirections and then find the "correct" host for one side of the transfer:davix/src/modules/copy/copy.cpp
Lines 229 to 298 in 23a591d
There isn't the analogous logic for the 2nd side of the transfer (which is stored in the
destination
variable regardless of push/pull mode), the Uri is passed as-is as a Source/Destination header, then the resolution of the redirects happens on the machine we're connected to: (the top-level redirector for each site isxrootd-vanderbilt.sites.opensciencegrid.org
andxrootd.cmsaf.mit.edu
, note that the Source side is the redirector and not the "resolved" version)Since libdavix doesn't resolve the COPY redirects for the destination, there's no way to report back the actual destination host (in this case). But, we do resolve the PROPFIND verb for the destination:
Is this on purpose? If instead
DavixCopyInternal::copy()
resolved redirects and stashed them intoDavix::DavixCopyInternal
, then accessors could be added toDavixCopy
for current source/dest Uris. The changes seem relatively straightforward to implement, but it is a behavioral change, so I don't want to implement if there would be no desire to add that functionality.The text was updated successfully, but these errors were encountered: