Running java process in a while loop using Runtime.exec() hangs on solaris

Question

I'm writting a multithreaded application in which I'll be starting multiple instances of "AppStartThread" class (given below). If I start only one instance of "AppStartThread", it is working fine. But if I start more than one instance of "AppStartThread", one of the threads hangs after some time (occasionaly). But other threads are working fine.
I have the following questions:
1. Is there any problem with starting a Thread inside another thread?. Here I'm executing the process in a while loop.
2. Other thing i noticed is the Thread is hanging after completing the process ("java ExecuteProcess"). But the P.waitFor() is not coming out.
3. Is it bcoz of the same problem as given in Bug ID : 4098442 ?.
4. Also java 1.2.2 documentation says:
"Because some native platforms only provide limited buffer size for standard input and output streams, failure to promptly write the input stream or read the output stream of the subprocess may cause the subprocess to block, and even deadlock. "
I'm running this on sun Solaris/java 1.2.2 standard edition. If any of you have experienced the same problem please help me out.
Will the same problem can happen on java 1.2.2 enterprise edition.?
class AppStartThread implements Runnable
public void run()
while(true)
try
Process P=Runtime.getRuntime().exec("java ExecuteProcess");
P.waitFor();
System.out.println("after executing application.");
P.destroy();
P = null;
System.gc();
catch(java.io.IOException io)
System.out.println("Could not execute application - IOException " + io);
catch(java.lang.InterruptedException ip)
System.out.println("Could not execute application - InterruptedException" + ip);
catch (Exception e)
System.out.println("Could not execute application -" + e.getMessage());

Answer 1

I'm writting a multithreaded application in which I'll
be starting multiple instances of "AppStartThread"
class (given below). If I start only one instance of
"AppStartThread", it is working fine. But if I start
more than one instance of "AppStartThread", one of the
threads hangs after some time (occasionaly). But other
threads are working fine.
I have the following questions:
1. Is there any problem with starting a Thread inside
another thread?. Here I'm executing the process in a
while loop.Of course this is OK, as your code is always being run by one thread or another. And no, it doesn't depend on which thread is starting threads.
2. Other thing i noticed is the Thread is hanging
after completing the process ("java ExecuteProcess").
But the P.waitFor() is not coming out.This is a vital clue. Is the process started by the Runtime.exec() actually completing or does the ps command still show that it is running?
3. Is it bcoz of the same problem as given in Bug ID :
4098442 ?.
4. Also java 1.2.2 documentation says:
"Because some native platforms only provide limited
ed buffer size for standard input and output streams,
failure to promptly write the input stream or read the
output stream of the subprocess may cause the
subprocess to block, and even deadlock. "These two are really the same thing (4098442 is not really a bug due to the reasons explained in the doc). If the program that you are exec'ing produces very much output, it is possible that the buffers to stdout and stderr are filling preventing your program from continuing. On Windows platforms, this buffer size is quite small (hundreds of characters) while (if I recall) on Solaris it is somewhat larger. However, I have seent his behavior causing problem on Solaris 8 in my own systems.
I once hit this problem when I was 'sure' that I was emitting no output due to an exception being thrown that I wasn't even aware of - the stack trace was more than enough to fill the output buffer and cause the deadlock.
You have several options. One, you could replace the System.out and System.err with PrintStream's backed up by (ie. on top of) BufferedOutputStream's that have large buffers (multi-K) that in turn are backed up by the original out and err PrintStream's. You would use System.setErr() and System.setOut() very early (static initializer block) in the startup of your class. The problem is that you are still at the mercy of code that may call flush() on these streams. I suppose you could implement your own FilterOutputStream to eat any flush requests...
Another solution if you just don't care about the output is to replace System.out and System.err with PrintStreams that write to /dev/nul. This is really easy and efficient.
The other tried and true approach is to start two threads in the main process each time you start a process. These will simply consume anything that is emitted through the stdout and stderr pipes. These would die when the streams close (i.e. when the process exits). Not pretty, but it works. I'd be worried about the overhead of two additional threads per external process except that processes have such huge overhead (considering you are starting a JVM) that it just won't matter. And it's not like the CPU is going to get hit much.
If you do this frequently in your program you might consider using a worker thread pool (see Doug Lea's Executor class) to avoid creating a lot of fairly short-lived threads. But this is probably over-optimizing.
Chuck