On 10/02/14 09:21, Matevz Tadel wrote:
> On 10/01/14 23:33, Lukasz Janyst wrote:
>> On 10/01/2014 06:42 PM, Matevz Tadel wrote:
>>> On 10/01/14 00:40, Lukasz Janyst wrote:
>>>> On 10/01/2014 12:07 AM, Andrew Hanushevsky wrote:
>>>>> The issue here is that the redirector is under no obligation to re-pass
>>>>> opaque information. The only thing it can do is to add additional opaque
>>>>> information. It's the client's responsibility to maintain the "tried"
>>>>> history. I don't think the old client does this and drops the history at
>>>>> some point (so, yes, it's a bug). The new client did much the same but
>>>>> that is being corrected in 4.1.
>>>>
>>>> The new client does not drop any CGI, we observed sometimes the
>>>> redirector would
>>>> ignore the tried= cgi though. The old client is deprecated, so if it
>>>> does not
>>>> work, stop using it :)
>>>
>>> Hmmh, we are using the new client ... also the xrdcp does used the new
>>> one, right? The logs I sent seem to be coming from the new client ...
>>
>> The one that you used in the test (xrdcp logs) is the old one.
>
> Ah, dammit, sorry ... the proxy does use the new client for sure.
>
> So, here is the thing with the new client, with debug 2 and 3:
>
> XRD_NETWORKSTACK=IPv4 xrdcp --debug 2 --force 'root://xrootd.unl.edu:1094///store/mc/Summer12_DR53X/TTJets_HadronicMGDecays_8TeV-madgraph/AODSIM/PU_S10_START53_V7A_ext-v1/00000/861247D0-E125-E211-97A8-485B39800C0F.root?hdfs_block_size=134217728&tried=xrootd.t2.ucsd.edu' /dev/null > ~/buf/xrdcp-tried-3.txt 2>&1
>
> http://uaf-2.t2.ucsd.edu/~matevz/tmp/xrdcp-tried-3.txt
>
> XRD_NETWORKSTACK=IPv4 xrdcp --debug 3 --force 'root://xrootd.unl.edu:1094///store/mc/Summer12_DR53X/TTJets_HadronicMGDecays_8TeV-madgraph/AODSIM/PU_S10_START53_V7A_ext-v1/00000/861247D0-E125-E211-97A8-485B39800C0F.root?hdfs_block_size=134217728&tried=xrootd.t2.ucsd.edu' /dev/null > ~/buf/xrdcp-tried-4.txt 2>&1
>
> http://uaf-2.t2.ucsd.edu/~matevz/tmp/xrdcp-tried-4.txt
>
> NOTES:
>
> 1. It still goes to xrootd.t2.ucsd.edu and to some UCSD server first but then also goes to DESY.
>
> 2. At some point this appears in xrdcp-tried-4.txt (and I've seen the same tried= in proxy logs, I also sent those in the firt mail):
> tried=+1213cmsxrootd1.fnal.gov1213xrootd.unl.edu
>
> Is this really a valid string? I mean, the only way I can see this coming back to UCSD is failing at the US redirector which then sets the tried= to both DNS aliases and goes to global redirector at cern. Then, this guy doesn't find it either and as the tried= is not good, goes back to the US and ends up at UCSD where it should have gotten at all.
OK, and here is a case where it goes to UCSD first, goes to global redirector and comes back to UCSD:
XRD_NETWORKSTACK=IPv4 xrdcp --debug 2 --force 'root://xrootd.unl.edu:1094//store/mc/Summer12_DR53X/DYJetsToLL_M-10To50_TuneZ2Star_8TeV-madgraph/AODSIM/PU_S10_START53_V7A-v1/00000/064C50C4-DA1B-E211-BA43-848F69FD289B.root?hdfs_block_size=134217728&tried=xrootd.t2.ucsd.edu' /dev/null> ~/buf/xrdcp-tried-5.txt 2>&1
http://uaf-2.t2.ucsd.edu/~matevz/tmp/xrdcp-tried-5.txt
XRD_NETWORKSTACK=IPv4 xrdcp --debug 3 --force 'root://xrootd.unl.edu:1094//store/mc/Summer12_DR53X/DYJetsToLL_M-10To50_TuneZ2Star_8TeV-madgraph/AODSIM/PU_S10_START53_V7A-v1/00000/064C50C4-DA1B-E211-BA43-848F69FD289B.root?hdfs_block_size=134217728&tried=xrootd.t2.ucsd.edu' /dev/null> ~/buf/xrdcp-tried-6.txt 2>&1
http://uaf-2.t2.ucsd.edu/~matevz/tmp/xrdcp-tried-6.txt
Matevz
########################################################################
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
|