So, thinking over many, probably not all, possibilities over my morning
coffee I come to the conclusion that is must be an MT unsafe problem.
Client A is opening two files X and Y, while X gets resolved the client is
using the URL for Y to access the file while the code thinks it's actually
using X. It just so happens that Y is located in the destination server so
it works, incorrectly. Why? because the URL is perfectly valid so it isn't
likely to be a storage overlay it is more likely to be a complete
substitution. That can only happen in the client. Is it possible that
there is a problem in the software framework that drives all of this?
Anyway, I am off to commue and will pick this thread up at my destination.
On Wed, 4 Dec 2019, Brian P Bockelman wrote:
>> I suppose it's also possible that something is messed up in the server and the file name is associated with the wrong data
>
> That's the very strange part of all of this. The DPM site never saw a request for the "correct" filename. That is, the client tried to open `81CB9803-B71C-464B-AD3F-5B53605EF41E.root` and recorded that in the client log. Around the same time (within a 5 second skew), DPM site logged an access for `B04C9BFD-09C6-0D4D-8E67-2D4DDCE88027.root`. The "correct" filename `81CB9803-B71C-464B-AD3F-5B53605EF41E.root` never existed at the DPM site and the client never logged anything about `81CB9803-B71C-464B-AD3F-5B53605EF41E.root`.
>
> So for DPM to be the culprit, it would have to advertise the availability of a file it never had and, for an incoming client, record the wrong filename in the log but send the client to the contents of the wrong filename.
>
> Theoretically, this can't be the fault of the DPM site, the redirector, or the client -- and yet it seems to happen multiple times a day!
>
>> Simple to test, open the file at the server and see if you get the right file.
>
> When done by hand, trying to open `81CB9803-B71C-464B-AD3F-5B53605EF41E.root` (which shouldn't exist at the DPM site) results in a file-not-found and opening `B04C9BFD-09C6-0D4D-8E67-2D4DDCE88027.root` results in the correct file contents.
>
> --
> You are receiving this because you are subscribed to this thread.
> Reply to this email directly or view it on GitHub:
> https://github.com/xrootd/xrootd/issues/1097#issuecomment-561761833
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or unsubscribe.
[
{
"@context": "http://schema.org",
"@type": "EmailMessage",
"potentialAction": {
"@type": "ViewAction",
"target": "https://github.com/xrootd/xrootd/issues/1097?email_source=notifications\u0026email_token=AA7NRDQDBWZ6S5WR4S77ARDQW7XGVA5CNFSM4JVKXSBKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEF57H5A#issuecomment-561771508",
"url": "https://github.com/xrootd/xrootd/issues/1097?email_source=notifications\u0026email_token=AA7NRDQDBWZ6S5WR4S77ARDQW7XGVA5CNFSM4JVKXSBKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEF57H5A#issuecomment-561771508",
"name": "View Issue"
},
"description": "View this Issue on GitHub",
"publisher": {
"@type": "Organization",
"name": "GitHub",
"url": "https://github.com"
}
}
]
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
