 |
 |
OK, not that this is going to solve anything but... "So for DPM to be the culprit, it would have to advertise the availability of a file it never had" When we were doing ATLAS that was an enduring problem for certain DPM sites. Yes, they would advertise files they never had. However, in that case, the client would simply give up when it went to that server. So, something else is going on now. Can we narrow this down? For instance, can we get a repeatable case? What if I search for the file you mentioned below, will I go to the wrong sever? Will the server provide the wrong file? Or those this just happen randomly? We need at least one file (hopefully more than one) that we can ask each redirector the state of the file and then follow up at each site. Finally, do we have an idea of what client version is involved here. Again, the redirector can't substitute file names (though it has that ability -- presumably that is not being used here). So, that would mean the client is doing that in some weird fashion. 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-561767017 ######################################################################## 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