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
|