Hi Pete,
your proposal makes sense to me. We'll discuss it on the POOL meeting
tomorrow
and will let you know after that.
Cheers, Dirk
On 7 Mar 2005, at 13:05, Peter Elmer wrote:
> [Add Dirk]
>
> Hi All,
>
> Once I removed the initial "if" block in TSystem::FindHelper(...),
> so that
> the PluginManager was used and I could specify an alternate to
> TNetSystem, I
> was able to read files via xrootd from CMS applications (i.e. via
> POOL).
>
> There was one additional thing, which IMO is actually a bad feature
> of POOL.
> When it opens a file read-only in RootDBase::open(...), it does a:
>
> Bool_t result = gSystem->AccessPathName(nam.c_str(), kFileExists);
>
> up-front _before_ it even tries to do the TFile::Open. While this
> makes sense
> in the write or update case, I think it makes a lot less sense in the
> read-only case. This is particularly true in situations where:
>
> o There may be multiple replicas around to read and the decision
> about
> which will be read takes place as a result of the TFile::Open.
> (The
> client could even wind up using more than one if the first copied
> found
> became unavailable and it had to switch.)
>
> o The file may be obtained at file open time from a MSS or even from
> another site behind the scenes. In this case the mechanics for
> doing
> the heavy work are only triggered by a TFile::Open (or an explicit
> prestage/prepare, which if done in this particular case would be
> redundant given the immediate TFile::Open)
>
> With xrootd (and other systems, too) the more appropriate thing to
> do in
> the read-only case would just be to open the file (since that was the
> plan
> anyway) and check afterwards to see if the file open succeeded. One
> could
> probably hack around this by providing a ::AccessPathName
> implementation for
> xrootd which gives a fake answer, but the best solution would be to
> modify
> what is in POOL (or at least provide an option to change the behaviour
> for
> read-only). Dirk, what do you think?
>
> (For the moment I just faked my around this in the alternative I
> provided
> to TNetSystem when using xrootd.)
>
> Pete
>
> On Mon, Mar 07, 2005 at 01:11:14AM +0100, Peter Elmer wrote:
>> Hi Fons and Gerri,
>>
>> I found another instance of a hard-coded check on "root://" in
>> TSystem::FindHelper(...), namely:
>>
>> // create new helper
>> TRegexp re("^root.*:"); // also roots, rootk, etc
>> TString pname = path;
>> if (pname.Index(re) != kNPOS) {
>> // rootd daemon ...
>> helper = new TNetSystem(path);
>> } else if (!strcmp(url.GetProtocol(), "http") &&
>> pname.BeginsWith("http")) {
>> // http ...
>>
>> } else if ((h = gROOT->GetPluginManager()->FindHandler("TSystem",
>> path))) {
>> if (h->LoadPlugin() == -1)
>> return 0;
>> helper = (TSystem*) h->ExecPlugin(0);
>> }
>>
>> This should probably be changed to use the PluginManager to find
>> TNetSystem.
>> It looks like most (all?) of the functionality is there in the
>> XrdClientAdmin
>> so presumably a "TXNetSystem" can be made. Fabrizio, what do you
>> think?
>>
>> Presumably this can be done as part of the merge of TXNetFile with
>> the posix
>> client. Do you know of any backwards compatibility issues which will
>> make it
>> difficult for a TXNetSystem to be backwards compatible with rootd
>> (using
>> TNetSystem)?
>>
>> Pete
>
>
>
> -----------------------------------------------------------------------
> --
> Peter Elmer E-mail: [log in to unmask] Phone: +41 (22)
> 767-4644
> Address: CERN Division PPE, Bat. 32 2C-14, CH-1211 Geneva 23,
> Switzerland
> -----------------------------------------------------------------------
> --
