 |
 |
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 or view it on GitHub: https://github.com/xrootd/xrootd/issues/1097#issuecomment-561771508 ######################################################################## 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