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.
This archive was generated by hypermail 2b29 : Thu Jan 01 2004 - 17:50:12 MET