 |
 |
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