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