Groovy and Grails Plugin Version: 1.3 Source: NetBeans IDE Dev (Build 200806230002)
When clicking the Stop button in the NetBeans output window of a running grails application, the java process is not
terminated. Rerunning the app from NetBeans (or running "grails run-app" in a terminal window) results in a long list
of "java.net.BindException: Address already in use: bind" errors. Using the Windows task manager to terminate java
processes from previously running grails apps corrects the problem. This problem has occurred on both Windows XP and
you gotta have "taskkill.exe" in your path. Could you verify this? It's *not* shipped with the Home edition of MS Windows XP.
taskkill.exe is in the c:/windows/system32 directory, which is in my path. Typing "taskkill /?" at a command prompt
returns the taskkill help.
This is known win problem - it is quite hard to guarantee process tree to be killed on windows (at least from java).
Attaching the patch that could fix this on the level of extexecution API. The patch is using winp library:
Created attachment 64346 [details]
the patch (using winp)
I've investigated some other methods to kill process tree on windows. AFAIK there is no reasonably reliable solution
other than usage of native code. Other options are:
taskkill, kill, pskill - only on some versions and editions of windows, needs to know pid - native call to figure it out
jna - the native code is not just a simple call (could be really messy), unclear which jna.jar (or custom one) should be
Kohsuke's code seems pretty usable, I'm not sure about the MIT license and win64 compatibility.
Jesse, just in case you had to solve this already... Any comments/preferred solution?
Thanks for any suggestions.
Groovy issue was workarounded in 66184693d711.
However this is a generic issue with destroying the process tree on windows and is related to extexecution. Changing
General solution to what? If you are referring to Ant builds, these just call Process.destroy() if you click Stop; it is
up to the process being run to kill any children it might have spawned. (In the case of NetBeans IDE or platform apps,
this is handled on Unix system using some Bourne shell magic, and on Windows probably not at all.)
I've meant any process run from the ide which can be terminated by the user. While destroying the process on *nix works
fine including the children it does not work on windows.
This is trouble when invoking any batch script (grails.bat for example). We could do some magic to control this
particular case and kill spawned children, but that would need tracking changes in such script. When we will provide
some "External Tool" support it is impossible to do so. Users will then comply about active processes in the system
which should not exist anymore.
So I'm trying to find out proper solution for killing (destroying) the process including its children on windows.
Kohsuke (and others as well) had to solve exactly the same problem in hudson. He end up with dll - I do not have any
better solution. So what I'm proposing is to put this solution to NetBeans (extexecution).
http://bugs.sun.com/view_bug.do?bug_id=4770092 is related to the same problem.
"destroying the process on *nix works fine including the children" - this is not true, I think. Process.destroy() on
Unix just sends SIGTERM to the actual process, which may result in it being killed while children remain alive.
In the case of killing platform*/lib/nbexec launched from Ant for module development, we work around this problem by
having that script capture SIGTERM and kill the Java process too. (bin/netbeans exec's nbexec so its own process is
gone, but nbexec must remain running so it can implement AU restart.)
Ctrl-C from a shell actually traverses the transitive process group and kills them all; native code for Unix systems
could do the same for us. For Windows it is trickier because (as I understand it) there is not a standard API to get a
transitive subprocess graph except the Win2000+ "Job".
BTW I would recommend use of JNA rather than shipping *.dll/*.so. It is likely to be easier to maintain, as there are no
binary files to keep in source control (other than JNA itself) and you don't need a special IDE or build tool to patch
the native code, just a Java editor. We include JNA in the platform cluster already.
At least on Unix, getting the PID from a Process object is easy using reflection (in the Sun JRE impl at least).
This is an enhancement. In groovy this is already solved.
This is still causing problems. Could we incorporate winp library (now 64 bit is available) and take the best effort
I think this problem will become more severe as we are adopting more and more external tools (grails, maven, php...).
Created attachment 84235 [details]
api change to allow process killing as a service
the api (please review)
the provider module
maven execution using the api
I'm going to move DestroyUtils to org.netbeans.api.extexecution.ExternalProcessSupport and I'll remove the String
constant which is actually not used anywhere.
no objections, however please note that the constant is used in the maven module already.
desc16 fixed: http://hg.netbeans.org/main/rev/cedfd412990b
Integrated into 'main-golden', will be available in build *200907030200* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
User: Milos Kleint <firstname.lastname@example.org>
Log: #138116 add api to allow pluggable means of destroying an external process.
[JG01] Javadoc for 'env' param to destroy(...) should be made clearer, especially why a Map is passed which might have
multiple keys (what would the behavior then be?).
[JG02] It is not acceptable for WrapperProcess and MavenCommandLineExecutor to implicitly share a constant. If this
value is magical then it needs to be exposed in the API.
Re JG01: Updated.
Re JG02: It is not a magic value. Maven and extexecution are using different variables now.
Created attachment 84530 [details]
patch JG01 & JG02
If there are no more objections, I'll apply the patch and close the issue tomorrow.
Fixed in web-main 5e107d3fef7a.
Also fixes arch.xml & apichanges.xml.
Integrated into 'main-golden', will be available in build *200907110200* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Log: #138116 Stopping a running app doesn't stop the child process