 |
 |
Hi Andy, I think I figured this one out... the second copy I was sure was there in fact was inaccessible, but the monitoring was broken. It's likely the client "did the right thing". Brian On May 3, 2011, at 10:16 PM, Andrew Hanushevsky wrote: > Hi Brian, > > That scenario is plausible except that the client is supposed to go back to the first manager it encountered not the last one. So, if you started with the meta-manager you would go back to the meta-manager. Whatever manager you initially contacted (generically we say the first point of contact in the protocol irrespective of what it is). Do you have a client trace handy? > > Andy > > On Tue, 3 May 2011, Brian Bockelman wrote: > >> Hi Xrootd-dev, >> >> I *think* we saw some non-optimal behavior of the Xrootd client with the CMS setup; I want to see if this chain of events would be plausible: >> >> 1) Client asks xrootd.unl.edu (US redirector) to prepare file foo. xrootd.unl.edu queries the various sites, and cmssrv32.fnal.gov (manager at FNAL) responds that the file is available. >> 2) Client later opens the file and gets redirected to cmssrv32, which redirects to a supervisor. At this point, the client is deferred because the server holding the file is overloaded. >> 3) Client goes back to the FNAL manager (cmssrv32), which reports there are no other copies of the file >> 4) Client gives a fatal error message. >> >> Basically, because the client appears to go back to cmssrv32.fnal.gov instead of xrootd.unl.edu, it is unable to find the file. >> >> Is this a plausible sequence? If so, is there a way to have the client return to the meta manager? >> >> Thanks, >> >> Brian