Hi Rene,
Thanks for your suggestion, and I find that I am able to solve the
first of the two problems in the message below with a slight variation
of your suggestion. I have added the two lines:
fTTree->AutoSave();
fTFile->SaveSelf();
just after tree fTTree has been created in file fTFile, and this avoids
having basket dumps in the open file when no keys have yet been written
to it.
However, I'm still having trouble with the 2nd problem described in the
previous note using more recent versions of root:
> I have also noticed that in the cvs version of root there is a problem when reading from open
> files such that I observe error messages of the type:
> Error in <TFile::ReadKeys>: reading illegal key, exiting after 0 keys
> and the open file is unreadable by the dispatcher because the read of keys from the file is
> aborted after this message. This error message was introduced in the
> 2003-03-01 version of root.
The procedure I use for autosaving the tree and directory keys on the daq side is:
TDirectory* savedir = gDirectory; // save current working directory
fTFile -> cd();
fTTree ->AutoSave(); // save tree to file
fTFile -> SaveSelf(); // save file directory containing this tree
savdir -> cd();
This procedure is invoked on user-specified time or entry intervals.
The procedure I use to read the keys from the open file on the dispatcher side is:
TDirectory* savedir = gDirectory;
fTFile->cd();
Int_t nkeys = fTFile->ReadKeys(); // This produces the Error messages in recent root
if (!nkeys) {
if (saveDir) saveDir->cd();
return false;
}
fFileEnd = PerFileManager::Instance().GetOpenedFile(fFullFilePathName)
-> HasFileEndKey(); // returns true if file has been closed by writer
// The following loop only pulls in a new tree if it differs in cycle
// number from a previously loaded tree to increase the efficiency in
// the case of the read of an open ROOT file.
bool newtree = false;
TKey *key;
TIter nextkey(fTFile->GetListOfKeys());
while ((key = (TKey*)nextkey())) {
if (strcmp(fTreeName.c_str(),key->GetName())==0) {
// A new tree will be pulled in only if it differs from previous
if ((fTreeCycle != key -> GetCycle()) || fFileEnd ) {
TTree* tree = dynamic_cast<TTree*> (key -> ReadObj());
if ( tree ) {
// Successfully read in tree. (Failure to read in tree may be due
// to a collision.)
// Delete old tree before replacing it with new
if (fTTree) delete fTTree; fTTree = 0; fTBranch = 0;
fTTree = tree;
fTreeCycle = key -> GetCycle();
newtree = true;
}
else {
MSG("Per",Msg::kInfo)
<< "PerInputStream experienced a recoverable collision reading tree "
<< fTreeName << " cycle " << key -> GetCycle() << "\nfrom file "
<< fFullFilePathName << "." << endl;
}
break;
}
}
}
...
On the other hand, I find that when I comment out the lines in TDirectory.cxx
associated with the Error message cited above, I can use cvs root
with our dispatcher/daq system.
Thanks again for your help,
-Sue
Rene Brun wrote:
> Hi Susan,
>
> The solution to your problem is to call TFile::Write after having
> created your Tree. See an example in the attachement
>
> Rene Brun
>
> On Tue, 3 Jun 2003,
> Susan Kasahara wrote:
>
> > Hi roottalk,
> > We are experiencing a problem with our dispatcher/daq configuration when using recent
> > versions of root. This configuration is such that the daq writes records to root trees which
> > are autosaved to file at regular intervals. The dispatcher reads the trees from the open
> > file and serves the data to clients while the data file is still being written to. This system has
> > worked for us for more than a year at our detector site.
> > We recently upgraded root at the detector site to v3.04/02. This version (and versions
> > more recent than this) seems to have a problem when reading open files when the file
> > has had baskets dumped to it but no trees yet autosaved to it. If the dispatcher should
> > attempt to read the file when the file is in this state (baskets dumped, but no autosave) the result is:
> >
> > Warning in <TNetFile::Init>: file root://daqdcp.minos-soudan.org//F00014618_0000.mdaq.root probably not closed, trying
> > to recover
> > Warning in <TNetFile::Init>: no keys recovered, file has been made a Zombie
> >
> > This is something new that is different than the previously experienced "normal" response of
> >
> > Warning in <TNetFile::Init>: file root://daqdcp.minos-soudan.org//F00014618_0000.mdaq.root has no keys
> >
> > which still occurs when the file has been opened by the daq but no keys or basket dumps have been
> > written to the file. In the latter case, the dispatcher server responds by attempting to read the
> > file again after a short wait time. I am wondering if it is possible for root to not attempt
> > to recover the file automatically when the file is open, indicating its still being written to,
> > as it did in earlier versions of root.
> > I have also noticed that in the cvs version of root there is a problem when reading from open
> > files such that I observe error messages of the type:
> > Error in <TFile::ReadKeys>: reading illegal key, exiting after 0 keys
> > and the open file is unreadable by the dispatcher because the read of keys from the file is
> > aborted after this message. This error message was introduced in the
> > 2003-03-01 version of root.
> > Thanks for your help,
> > -Sue K.
> >
> >
>
> --------------------------------------------------------------------------------------------------------------------------------------------
> Name: junk.C
> junk.C Type: Plain Text (TEXT/PLAIN)
> Encoding: BASE64
This archive was generated by hypermail 2b29 : Thu Jan 01 2004 - 17:50:12 MET