 |
 |
What should be happening here, unless the gateway thinks it's not under the control of a redirector, is that the gateway would tell its redirector that the original file no longer exists and the rename target does exist. Now, it could be the case (though unlikely) that the subsequent stat is issued faster than the time it takes for the gateway to update the information in the redirector. So, is the stat issued by the client doing the rename or by some parallel client? Another issue here is that http was never designed to deal with such scenarios. In xroot protocol you do have the option to query the server directly and refresh the redirector's cache. This actually happens automatically when a mismatch is discovered in the redirector's cache. However, doing this all the time would quickly bring the whole system to its knees under even medium sized loads. So, it's not a practical option. So, it seems we need to delve into this deeper to find out a) what happened to the notification that should have been sent to the redirector, b) what is the actual timing of the stat call, and c) if you issue the stat call directly to the gateway does it correctly respond? -- Reply to this email directly or view it on GitHub: https://github.com/xrootd/xrootd/issues/1703#issuecomment-1122592059 You are receiving this because you are subscribed to this thread. Message ID: <[log in to unmask]> ######################################################################## 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