Sim IJskes - QCG wrote:
On 11/27/2010 05:32 AM, Patricia Shanahan wrote:
Scheme 1: Modify each class that calls Runtime.getRuntime.exec to
register a shutdownHook to destroy the Process that exec returned.
Scheme 2: Require each public static void main(String[]) method in River
to log the pid of its process in a log message with a specific format.
Write a program that scans the log file for those messages, and kills
each process.
What about having the VM kill itself when a keepalive condition does not
occur anymore. A watchdog. The best way for such a condition is a
condition managed by the OS. A socket whould be a good candidate. In
fact there is already such a mechanism. Just look for KEEPALIVE_PORT in
the QA harness, It is in MasterHarness and SlaveHarness.
The strategy would be as follows (not verified with the actual
keepaliveport implementation).
The coordinating process opens a ServerSocket. The subordinate processes
try to open this socket. If they fail or if the socket is closed at a
later stage, they selfdestruct.
I just coded the HeartOfTheMachine because i needed to be sure, and it
was much simpler than verifing the keepalive port mechanism. But i
prefer the keepaliveport. If we agree on this mechanism beeing
theoretically foolproof, we can have a look if this mechanism is
implemented for every test scenario, and fix it where its not.
Subject to sorting out the technical details, I like this approach.
Is the HeartOfTheMachine the mechanism that kills a hung test after 4
hours? I happened to leave a failing run of my current debug project
sitting around last night, and by this morning it had been interrupted
and shut down.
I think the general approach should be to do something in every main
method. Finding the main methods is not that hard. We can have a utility
class that has a static method that every main method calls, and make
the static method set up for rapid shutdown.
Patricia
