[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
[stellation-res] Test Failure under Sun's SDK v1.4.1
|
Hi there,
> I then fired up current build.
>
> Things went fine until it got to test 2, and then the machine hung!
>
> I suggest you try IBM's JDK.
>
> You have taken me on a trip down memory lane. Let's see if I ever had
> problems with Sun software -- well there was a project call Jikes.
>
> dave
Well, I know you had suggested that I put this aside until you have
more time to look at it. But I just couldn't put it down. There are
two practical benefits to this persistent (or perhaps stubborn)
streak. First, I've learned a more about Stellation by adding excess
logging statements starting where the command is parsed and running
all the way down into the cli.workspace package.
The other benefit is that I found the culprit for the hanging under
Sun's JDK! The Exec.exec method executes other commands using the
Runtime.exec() call. Most of the time this call returns. Through the
magic of Sun's JDK, sometimes it just doesn't. I've taken two steps
to verify my hypothesis. First, I've enclosed just that Runtime.exec
call in logging statements (just before and just after). Whenever the
program hangs, the before statement prints out a log message, and the
after statement does not.
The second step I took was to change the _useJavaFile variable in
Files.java to true for OS.UNIX rather than false. This eliminates a
great many calls to the Exec.exec method during the first several test
scripts, as the 'find' command is not used. When I do this, the tests
get farther. When they do fail, it's because of another call to exec.
I took a brief look around the bug database for Java at Sun. I did
not see any entry describing this kind of hang under linux. It wasn't
a thorough search, though, so they may have a bug entry for it of
which I'm not aware. (I haven't reported it yet because I'd need to
boil it down to a small example program I can hand them.) I also
haven't yet characterized under what circumstances a Runtime.exec()
call fails. My first guess would be that Sun's implementation of
Runtime.exec() is leaking resources like a sieve.
I know I can eliminate some of the calls to exec() by changing
_useJavaFile to true. Are there flags to disable other exec calls?
Or are some of them just fundamentally necessary to Stellation's
operation? I know the easiest solution is to switch to IBM's JDK.
But I imagine there's a wide enough audience of people using Sun's JDK
(such as it is) who want to use Stellation to make it worth my looking
into how to make it work.
Jeffrey
(Below I'm including a diff file that will take an Exec.java file and
turn it into Exec.java.new. The change adds a few logging statements
around the Runtime.exec() call. When the tests are run with the -d3
flag, these logging statements show that the hang with Sun's JDK 1.4.1
occur in the call to Runtime.exec.)
*** Exec.java Sat Dec 21 00:31:25 2002
--- Exec.java.new Sat Dec 21 00:31:11 2002
***************
*** 19,24 ****
--- 19,26 ----
import java.io.OutputStream;
import java.io.PrintStream;
+ import org.apache.log4j.Logger;
+
import org.eclipse.stellation.util.StringList;
***************
*** 58,66 ****
File workingDirectory
) throws IOException {
Runtime rt = Runtime.getRuntime();
!
Process process = rt.exec(cmdarray,null,
workingDirectory);
// Copy stdin to input of command
OutputStream outStream = process.getOutputStream();
PrintStream ps = new PrintStream(new BufferedOutputStream(outStream));
--- 60,70 ----
File workingDirectory
) throws IOException {
Runtime rt = Runtime.getRuntime();
!
! logger.debug( "About to exec." );
Process process = rt.exec(cmdarray,null,
workingDirectory);
+ logger.debug( "Returned from exec." );
// Copy stdin to input of command
OutputStream outStream = process.getOutputStream();
PrintStream ps = new PrintStream(new BufferedOutputStream(outStream));
***************
*** 121,124 ****
--- 125,130 ----
int rc = Exec.exec(argv, null, null, null, userDirectory);
return rc;
}
+
+ static final Logger logger = Logger.getLogger(Exec.class);
}