471,896 Members | 2,004 Online
Bytes | Software Development & Data Engineering Community
Post +

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 471,896 software developers and data experts.

process.destroy() does not kill the subprocess

127 100+
Dear All,

I have an issue with destroy() method of java.lang.Process class. All what I am trying to do is, controlling the execution of one program through another. Let's say, Program B has to be executed conditionally through Program A based on the commands it gets from the user. Let's say, we have two inputs, "start" and "stop" to drive the Program B.

I have thought of various alternatives.

(1) Using Thread to control the execution of Program B. But then stopping a process means via a thread is not allowed as the related methods are deprecated (stop/suspend etc.,)
(2) Using ThreadGroup ( to have only one thread as its member) and calling 'destroy' on the group. But it again falls on the same track as every thread should be stopped before the destroy operation is attempeted.
(3) Process/ProcessBuilder via Runtime -- seems to be the better way to obtain a process reference and call destroy(), waitFor() etc., to control the spawned child process.

I went ahead with 3rd approach and all went fine till the spawning of the new child process. When the time came to stop the execution (ideally speaking, to stop! but practically destroying/killing the child process), it breaks! .

My main program (Program A) gives an information that the Program B stopped successfully (as I do store the process references in a Map and retrieve the same before destroying the process) and this operation succeeds. But it does NOT really reflect in reality and my child program still runs as if it was never interrupted. Looks like the child process gets disjoint with the parent process and hence the link gets cut between the two. I have to invoke my Program B via "cmd.exe /C java.exe ProgramB". I do use Windows XP and JRE 1.6.0_10 beta.

Program B is a java program which just keeps writing the date and time into a log file on an interval of 1 second. Program A has the main() method and gets the "threadName && start/stop" inputs from the user and retains the information into the Map. I am not dependent on my Program B's output and hence I don't invoke waitFor() and exitValue() methods.

If required I can post the program here.

Having been searching in the internet for a long time but nothing seems to be fruitful. Some says that it may be a bug with JVM. But I don't think so.

Few typical examples of this kind is, Tomcat catalina (startup.bat/shutdown.bat) and Quartz Job Scheduler -- they do get a command from the user 'start/stop' to fire an action!

Looks strange as the API does NOT guarantee the behavior as per the Specification. It says,

Expand|Select|Wrap|Line Numbers
  1. public abstract void destroy()  
  2.          Kills the subprocess. The subprocess represented by this Process object is forcibly terminated.   

Do I miss something here? Any suggestions would be of a great help!
Jun 9 '09 #1
6 16578
13,262 8TB
Going back to your first alternative, just because the stop method is deprecated doesn't mean you can't stop a thread from executing. You can still use a flag to control a while loop that runs in the thread's run method. All you do is switch the flag when the stopping condition is reached. Once the run method ends, the thread will stop.
Jun 9 '09 #2
127 100+
Hi r035198x,

Hope you are doing fine. Thanks for the reply!

Yes of course. You are right. Just because a method is deprecated does not mean that we can't/should not use. However, this usage is strictly NOT suggested by Sun itself as they are potentially dangerous (wrt the locks the objects might have acquired) Reference URL -> http://java.sun.com/j2se/1.5.0/docs/...precation.html.

I was about to have the other alternative you suggested. Like having a logical lock to control the execution. Let me test the other possibilities and get back.

Jun 9 '09 #3
13,262 8TB
Read my reply again. I didn't say that you should use the stop method, I pointed out how to stop a thread without using the stop method.
Jun 9 '09 #4
127 100+
Yes, that is what I also meant. Apologize if it was not reflected in the words.
Jun 9 '09 #5
13,262 8TB
I see no need for pursuing all these other alternatives. You can stop a thread using the approach I posted above. It's also described in that link you posted above and suggested as best practice.
Jun 9 '09 #6
127 100+
yes of course. but I felt proceeding with the process itself as I can get hold of the entire process so as to destroy/kill at once completely! Thus, have chosen this way.
Jun 9 '09 #7

Post your reply

Sign in to post your reply or Sign up for a free account.

Similar topics

5 posts views Thread by Natan | last post: by
1 post views Thread by Manfred Braun | last post: by
3 posts views Thread by elrondrules | last post: by
4 posts views Thread by Richard Rossel | last post: by
12 posts views Thread by bhunter | last post: by
1 post views Thread by Salim Fadhley | last post: by
2 posts views Thread by =?Utf-8?B?WVhR?= | last post: by
reply views Thread by YellowAndGreen | last post: by

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.