XrdCl: Get last manager?

[bbockelm]

Hi,

We would like to know the name of the previous manager encountered (i.e., the thing before the current data server). Can this be one of the things I can retrieve via GetProperty?

We're hoping to use this to solve a dCache problem: the dCache "door node" is registered as part of the Xrootd federation, but the dCache "pool node" is not. Hence, if we do something along the lines of:

root://redirector.example.com//store/foo?tried=poolnode.example.com

then the redirector may still redirect us to poolnode.example.com (because it only knows about doornode.example.com). If we knew the last manager encountered in the client, we could exclude the whole site.

Brian

[ljanyst]

With a response to an async request you get a list of all hosts contacted to fulfill this request, together with some extra info about them:

https://github.com/xrootd/xrootd/blob/master/src/XrdCl/XrdClXRootDResponses.hh#L815

Can you use these?

[ljanyst]

In 4.1 if a data node fails and you are in federation context (ie. a metamanager was encountered on the way) the doornode.example.com will be excluded as well.

[ljanyst]

Correction, it's there in 4.0.4 as well.

[bbockelm]

Nope - I don't think that logic works for our case. We successfully open the file at poolnode.example.com, but are trying to probe the federation for additional sources.

I haven't looked at the HostList - this is an asynchronous client, so it probably will work for us. What's the sorting? Last host encountered is listed last?

[ljanyst]

Yes, they come in the order they were encountered. The flags field gives you info about the kind of host it was ((meta)manager/disk node).

[bbockelm]

I see that HostInfo::flags is a uint32_t, not an enum (as is preferred ;)). Is the set of possible flags documented?

[bbockelm]

Shoot - there's one case where we use the synchronous Open. Is there a mechanism to access the HostList then?

[ljanyst]

For the first question: shoot, I, indeed, should have used an enum. I will add one for just testing the values (the int will have to stay an int) or I will add some accessors to the struct, like isThis or isThat, for the time being, please look at these:

https://github.com/xrootd/xrootd/blob/master/src/XProtocol/XProtocol.hh#L61

For the second question: there is not way, but synchronous open is implemented in terms of asynchronous one in 5 lines of code:

https://github.com/xrootd/xrootd/blob/master/src/XrdCl/XrdClFile.cc#L110

[bbockelm]

Alright - it stinks that I have to reimplement the SyncResponseHandler (see bbockelm/cmssw@68cdff0#diff-bbd7818ea01b0d11e451fbaadc6b68e3R1). However, I got it working ... closing out this ticket.

[ljanyst]

Great. Be careful with dCache: https://sft.its.cern.ch/jira/browse/ROOT-6639

[bbockelm]

Yeah - I saw the auto-negotiation code, but don't want to use it as I want to avoid round-trips with the server and don't have the energy to make this asynchronous right now.