process.destroy() does not kill the subprocess

[itsraghz]

Dear All,

I have an issue with destroy() method of java.lang.Proce ss 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,

[B]public abstract void destroy() [/B] 
		 Kills the subprocess. The subprocess represented by this Process object is [B]forcibly terminated[/B].

Do I miss something here? Any suggestions would be of a great help!

[r035198x]

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.

[itsraghz]

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.

Thanks.

[r035198x]

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.

[itsraghz]

Yes, that is what I also meant. Apologize if it was not reflected in the words.

[r035198x]

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.

[itsraghz]

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.