Print

Print


The only case that the server sends a client a tried CGI element is when 
the server redirects the client elsewhere and does not want the client 
comming back. ATLAS uses this mechanism via an ENOENT static redirect to 
maneuver the redirection tree in a predictable way. I beleive they only 
configured this in actual redirectors, though you could do it at the 
server level. See the xrootd.redirect config option.

Andy

On Fri, 3 Oct 2014, Lukasz Janyst wrote:

>   The "tried=" CGI was supposed to be a tool for the client to tell the 
> server that it has tried a given host and failed and thus should not be sent 
> to this host again. The client handles this CGI by calling 
> XRootDMsgHandler::UpdateTriedCGI() which then results with a call to 
> MessageUtils::MergeCGI() with "replace" parameter set to false:
>
> https://github.com/xrootd/xrootd/blob/master/src/XrdCl/XrdClMessageUtils.cc#L236
>
>   This causes accumulation of all the values of a given CGI parameter, ie. 
> it creates a comma-separated list of values.
>
>   The CGI returned by the redirector is handled differently. Any new value 
> returned by the server should supersede any previous value a given parameter 
> had. The client handles this by calling 
> XRootDMsgHandler::RewriteRequestRedirect(), which then calls 
> MessageUtils::MergeCGI() with "replace" parameter set to true.
>
>   The CGI is an integral part of the message being sent and never gets 
> dropped. So everything in the client works exactly as intended.
>
>   Why would the server want to tell the client that it (the client) has 
> tried a certain other server and failed? This does not make a slightest 
> sense!
>
> Cheers,
>   Lukasz
>
>
> On 10/02/2014 06:24 PM, Matevz Tadel wrote:
>> The instances seem to be:
>> 
>> ...00C0F.root?tried=+1213cmsxrootd1.fnal.gov1213xrootd.unl.edu
>> 
>> and
>> 
>> ...00C0F.root?hdfs_block_size=134217728&tried=xrootd.t2.ucsd.edu
>> 
>> but maybe let's wait what Lukasz finds out from the client logs.
>> 
>> The first one does seem rather strange to me though, it comes from the
>> DNS aliases on regional meta-managers in the US :)
>> 
>> Matevz
>> 
>> On 10/02/14 00:44, Andrew Hanushevsky wrote:
>>> Well, the onlyh time a redirector would ignore a tried is if the tried
>>> were
>>> malformed. It's pretty precise on how things get excluded. So, I would
>>> like to
>>> see an instance where the tried was ignored.
>>> 
>>> Andy
>>> 
>>> On Wed, 1 Oct 2014, 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 :)
>>>>
>>>>   Lukasz
>>>> 
>>>> ########################################################################
>>>> 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
>>>> 
>> 
>

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