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
|