The 30 second timeouts that tend to cause the above errors (when corba methods take longer than 30 secs to time out) have been tracked to the ipc package: lines like
string IPCCore::timeout_ = getenv( "TDAQ_IPC_TIMEOUT" ) != 0
? getenv("TDAQ_IPC_TIMEOUT" )
: "30000";
in /scratch/tdaq/online/online-00-22-00/installed/../ipc/ipc-04-00-09/src/core.cc which show us that if you don't want these errors to occur one way of fixing the problem is to increase the TDAQ_IPC_TIMEOUT to a larger value (in miliseconds!).
In a mail to Dave, I suggested that the following might be good *practical* help for how to work around a package running into delay problems ... but I haven't heard confirmation that the suggestion works, or heard back on the *best* way to proceeed:
Date: Wed, 12 Jan 2005 15:27:11 +0000 (GMT) From: Christopher Lester <lester@hep.phy.cam.ac.uk> To: Dave Robinson <robinson@hep.phy.cam.ac.uk> Subject: TDAQ_IPC_TIMEOUT
Yes ... it really does seem to be as indicated on the wiki page. I can't see a work around that does not involve changing one of the sets of lines like:
<rel name="NeedsEnvironment" num="2"> "Environment" "CLASSPATH" "Environment" "PATH" </rel>
to
<rel name="NeedsEnvironment" num="3"> "Environment" "CLASSPATH" "Environment" "PATH" "Environment" "TDAQ_IPC_TIMEOUT_FOR_PACKAGE_X" </rel>
and similar (the above example was taked from installed/config/databases/SctApplications?.data.xml)
This would also necessitate adding defn somewhere like:
<obj class="Environment" id="TDAQ_IPC_TIMEOUT_FOR_PACKAGE_X"> <attr name="Variable" type="string">"TDAQ_IPC_TIMEOUT"</attr> <attr name="Value" type="string">"999000"</attr> </obj>
(note the MILLI-seconds) which is modelled on the classic:
<obj class="Environment" id="CLASSPATH">
<attr name="Variable" type="string">"CLASSPATH"</attr>
<attr name="Value" type="string">"${CLASSPATH}"</attr>
</obj>
taken from one of the schema files.
--
It *may* also be possible to set one value of TDAQ_IPC_TIMEOUT to a large value in the "start" script, but I am not sure that it will propagate to processes working on other machines ... my guess is that it won't ... but if you find that it does, let me know! I'd be interested.
Let me know if you find an alternative work around ...
Chris
Update 2005/01/26 -- CGL -----
The above workaround was used to extend the timeout for the CalibrationController in SCT_core.data.xml for a while (versions 1.3 and 1.4 of this file) but I have now implemented non-blocking RawScans?, so in version 1.5 of the file, I have removed the work around.
So this issue is (hopefully) closed.