[
https://jira.codehaus.org/browse/SUREFIRE-946?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=316791#comment-316791
]
Kristian Rosenvold commented on SUREFIRE-946:
---------------------------------------------
{begin rant}
Hundreds of tear-stained blog posts have been written about java process
forking and the jdk issue tracker is littered with unsolved bugs in process
forking. Unfortunately the people who wrote ProcessBuilder did not fully
appreciate all the subtleties of these bugs. I spent quite a lot of time trying
to make ProcessBuilder stable for the selenium project, and my conclusion was
that ProcessBuilder does not handle the process streams correctly, and was
broken and deadlock prone for all released jdk versions at the time I tested
this (about a year ago).
This is the code that runs millions of forks every day and has done so for
numerous years, in terms of stability and reliability it outperforms
ProcessBuilder by a wide margin.
{end rant}
I have long since supressed the details of the numerous traumatic ways process
forking can fail regarding stream handling. Looking at the code now, I think
the issue might be that the streams are not closed in the shutdown hook (If I
remember correctly the kill -3 will not run the finally block in
executeCommandLineAsCallable). I think the process failing to exit is simply
because
we're not closing the streams properly.
I'm thinking adding these to the current shutdown hook might do it:
if ( inputFeeder != null )
{
inputFeeder.close();
}
outputPumper.close();
errorPumper.close();
(It's probably wise trying to fix this one problem first before moving onto
more esoteric stuff like heartbeats...)
I clearly seem to remember one of the tearstained blogposts about terminating
forks that were waiting for output from stdin. The details escape me ;)
In this context we might consider switching rpc mechanism entirely to something
like named pipes. The 2-way communications between two java processes using
stdio is really one of the reasons I've held back on implementing this feature
in the first place. Suggestions are welcome as I'm still thinking about this on
the 5th year or so ;)
BTW: The shutdown hook is necessary for some reason (probably more bugs). The
explanation can be found by looking at history for
ant/commons-exec/plexus-utils. I believe the original commit in plexus has a
fairly extensive issue history.
> Maven hangs on SIGTERM when using Surefire forking
> (CommandLineUtils.ProcessHook)
> ---------------------------------------------------------------------------------
>
> Key: SUREFIRE-946
> URL: https://jira.codehaus.org/browse/SUREFIRE-946
> Project: Maven Surefire
> Issue Type: Bug
> Affects Versions: 2.13
> Reporter: Jesse Glick
> Attachments: stack.txt
>
>
> Java 7u7, Surefire with JUnit {{forkMode="perthread"}} + {{threadCount="1"}}
> + {{reuseForks="true"}}. After pressing Ctrl-C to stop the Maven test run,
> the process hangs and must be killed with SIGKILL. From the thread dump,
> {{CommandLineUtils.ProcessHook}} and {{StreamFeeder}} look responsible.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
