See also the OmniMigration page for staus, documentation and related topics.
Issues raised by Alan:
SCT/OmniMarshalling.huntested- Unit test in progress.
- Chris beware! this throws exceptions depending on thread ordering ... very odd.
sctConfIPC/marshalling.huntested- Once all the tests in SystemTests/ConfigurationTests? have been run, most of these are checked -- BruceGallop
- See also my comments about files called marshalling.h below -- ChrisLester.
- pmgSynch - what has happened to this.
- I've been assuming that it is simply not needed any more as I have only found it being used by Matt's "doSoon" kludges. I've been deleting it wherever I've seen it. -- ChrisLester
- This is/was needed because the SctApiServer? could start before the configuration server was running, which results in a crash when SctApiServer? tries to contact the config server in its initialisation... There may be a different way of solving this -- BruceGallop
- Indeed - the doSoon methods and pmgSynch stuff certainly weren't kludges! I had a quick look and it looks like PMG hasn't changed, so the PMG synch mechanism can still be used. However, it is necessary for the synch to occur after all the CORBA interfaces have been set up. The reason for this is that many processes grab references to other servers/CORBA interfaces as they start up, so each process needs to be fully started up before the next one begins. We did have some problems with this.... -- MattPalmer
- OK, I've put the pmg_sync() stuff back into the places I had commented it out of. The prescription Matt proposed was to replace the lines containing "doSoon" to a straightforward call to pmg_sync(). This will therefore be just before a run() statment. I have made these changes, they compile, but their effectiveness remains untested.
- Update: at run time, pmg_sync routines need an env variable PMG_SYNC_FILE to point to a "synchronisation file" they use to coordinate activities (whether this is a file they only need to READ to determine allowable orderings, or whether they write to it to say they are "now up" I am not sure). Anyway, many test routines (eg "make run" in SystemTests) cause processes to be started up NOT under the control of a pmg mangager, so none of these environment vars or sync files are set up and this leads to run time errors that presumably mean that sometimes processes are brought up in the wrong order and this leads to unpredictability in the test outcomes. There seem to be both pros and cons concerning possible resolutions: (a) start processes with pmg, but then lose valgrindability, (b) ignore warnings and tolerate error messages at expense of run-time stability.
- RunControl needs to be fixed in sctConf
- The idl interface name for the SctApi seems to have changed to SctApiIPC? -> Chris can this be changed back?
- Decision reached 1/7/2004 to keep the change to the interface name. (Alan and Chris)
Issues raised by ChrisLester:
Current:
- See RegisterErrors
- Boc scans seem to be broken and have possibly never worked under this release. See MergedBocScanErrors and
- Bruce and I added a schema and data thingy for a TDAQ_DB_SCHEMA in DaqEnvironment?.data.xml and in SCT_test.data.xml in config/databases. One does actually wonder whether these variables should actually be set by the TDAQ people in TDAQ_DB_PATH/online/segments/commen-environment.data.xml.
- Matt reminded me that it's easy to forget to call the deactivate method in the destrictor of all the IPCNamedObjects?. [I have been forgetting to do so thus far.] Watch out for this Alan!
- Update: The deactivate method we have been advised to call does not appear to be a member of any of the classes in the ipc package, so I have sent a mail to Serguei Kolos asking him to clarify the statements he made in the IPC migration page he wrote (see DocumentationForOmniMigration).
- Update: Sergei has written a nice reply saying that the web-page documentation is not completely up-to-date and we should ignore the part mentioned here. We should instead bear in mind to ALWAYS create IPC{,Named}Objects with new, and NEVER delete them with "delete", only with _destroy(). (Chris)
- I must check that (In SctApiIPC?/SctApiServer?.cc) whenever I get an _ptr passed by value I immediately assign it to an _var and never use the _ptr again. This way I (think I) can avoid having to mess around with _duplication().
- Renamed the interface called Sct_SctApi::SctApi to Sct_SctApi::SctApiIPC? to remove hard-to-track-down namespace clashes that were causing the presultant POA_Sct_SctApi::SctApi's to namespace-clash with ::SctApi::SctApi's from $(ROOT)/SctApi/SctApi.h. This change may affect others.
- I don't (yet) understand the reason why the old SctApiServer?.h overrode an old "freeable" method called destroy(ipcStatus *). I have placed the contents of this old method in the new (mandatory) shutdown method od the new corresponding IPCNamedObject?. But this might be very wrong. Someone must check this out.
- SctApiServer? maintains a list of all the scans that have been done, basically for memory management purposes... Because SctApi doesn't know the Scan is a CORBA object it doesn't know when to delete it, and it needs to hang around after doScan has completed. Maybe destroy is the wrong place to delete the reference from the list -- BruceGallop
- This applies to BOTH the SctApiServer? AND the ScanServer? classes defined in the above file!
- Marshalling Issues.
- Combine all three marshalling files into one, perhaps in in its own package!
- SCT/src/OmniMarshalling?.h seems to include at least one mehtod that isn't used by anyone. Namely "copycorbatostdcollection". Maybe it should be deleted... It just seems like it should be useful, depends how easy it is to rewrite if it becomes useful?
- The one in SCT is meant to be generic stuff. SCT can't depend on sctConfIPC and SctApiIPC? otherwise you get circular dependencies. Another package seems a bit extreme :) -- BruceGallop
- There's an SctApiIPC?/marshalling.h and a sctConfIPC/marshalling.h that is now installed to ...../include/sctConfIPC/marshalling.h but which USED to be put in ...../include/sctConf/marshalling.h despite being part fo the sctConfIPC package all along, and I'm getting confused!
- Oops -- BruceGallop
- The length argument to SCT/OmniMarshalling?.h:copyCorbaToArray (and possibly length params to other routines in this class ... I haven't checked) is unnecessary and prone to error. This argument should be removed.
- I think that's there because in some cases the length can be known at compile time (eg mask and trim arrays in SctApi modify methods). I suppose this rather implies they should be CORBA arryays rather than sequences... Oh well... Yes it doesn't serve much purpose -- BruceGallop
- There are a number of pieces of duplicated code in SctApiIPC?/SctApiServer?.cc that could be separated out and turned into new corbaToXXX and xxxToCorba functions in one of the marshalling.h files.
- It is ugly that the package name Package=Sct_SctApi (which is used for the header export dir) in SctApiIPC?/Makefile does not correspond to the name of the package itself. In the long run, aim to fix this, along with Alan's suggestion to revamp sctConfIPC, SctApiIPC? amd sctConf altogether!
- To get AutoConfig? in SctApi to compile I had to add -lROSDebug to the list of linked libraries. (libROSDebug.so is part of DataFlow? in $DF_INST_PATH/$CMTCONFIG/lib). I don't know what this lib does.
- TriggerWrapper? and ScanWrapper? do not yet have well definied policies about whether or not they own the things they wrap. This should be addressed.
- Update: Well, now they have a construtor option that lets you choose whether you want them to own the references they wrap, so in principle they can be configured correcly if you know what you want. A first look seems to suggests that they should NOT own the things they reference, so I have set everything up with this non-owning policiy initially.
- I have used _NP_ref() a lot when using corba strings to initialise std::strings. Is this OK?
- The more I see of the new ipc stuff, the more I think we should be having every named object inherit from an ipcserver and use the inherited run/stop methods, as otherwise I think remote corba processes will not be able to unblock remote corba "servers". This means modifying the "main" programs of most of the updated portions of the code. Probably the shutdown() methods would also be modified to include stop calls.
- SystemTest? realated stuff
- If $SCT_DAQ_ROOT/installed/share/SctTestApiData/strun551_2.root is used by one of the AnalysisService SystemTests is needed, then why don't I have it? Should be in the rep or this dependence should be modified.
- Error in <TFile::TFile>: file /home/lester/working2/installed/share/SctTestApiData/strun551_2.root does not exist
- Aim to wget this from daves area if it's not there already .. robinson/public_html/rootFiles_run551.zip
- They're not in CVS because they're too big... They may be in one of the releases as well
- the PMG_SYNC_FILE env var (and associated touched file) seem to be needed by pmg_initSync, but do not seem to be set up by any run time script. This means the SystemTests don't run "out of the box".
- If $SCT_DAQ_ROOT/installed/share/SctTestApiData/strun551_2.root is used by one of the AnalysisService SystemTests is needed, then why don't I have it? Should be in the rep or this dependence should be modified.
Resolved
- To make every java util work, need to change add Dtdaq.ipc.init.ref=${TDAQ_IPC_INIT_REF} in place of -Dipc.ref.file=${IPC_REF_FILE} on the "java CLASSNAME" command line. This is tricky, as sometimes these calls to java are buried inside cpp source code, in bsh files, and in other scripts.
- Changed all of the above, excpept in possibly one place, where the gui makes a system call to "java productionDatabase blah blah blah" (or something similar) which I thought might not need to be altered ...
- Best way to handle exceptions in ConfigurationService?
- Catch and re-throw.
sctddc-00-00-02/src/SCTDdcRequest.cxxAbdel must check that the 5 changes labelled "#warning Check the above line 1/5 is correct" and so on are correct. (ChrisLester)- Done -- Abdel has said all changes are OK. Warnings have been removed from rep.
- Somehow a make in one of my working2 dirs (I don't know which one) caused the "IS tool" to "update" sctGUI/DisplayGUI?/IVScanControl?.java for me. [i.e. it overwrote it with something it generated] If sctGUI/DisplayGUI?/IVScanControl?.java is a "generated" file, should it really be part of the cvs rep? I would have thought not. Yet it is. Any comments?
- Removed from cvs -- Alan
- malloc's of char*'s should be replaced by new[] in both api and conf
- replaced by CORBA::string_dup's Alan
- In SCT/src/scripts, (almost) all files need some work. Have so far corrected the two Sequence files (DefaultSequence? and CharacterisationSequence?) and of the remaining tests, have corrected DefaultTest?, StrobeDelayTest and StrobeDelayScan?. There rest are still to do.
See also the OmniMigration page for staus, documentation and related topics.