Re: [stellation-res] Test Failure under Sun's SDK v1.4.1

[Dave Shields <shields@xxxxxxxxxxxxxx>]

On Sat, Dec 21, 2002 at 01:04:13AM -0500, Jeffrey Howard wrote:
> 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. 

Persistent? Stubborn? 
No problem -- these attributes are often found in good developers.


> 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?  

Many thanks for looking into this.

We use Exec to run 'diff' and to get file attributes via 'find'.

As a result, 'svc diff' is not supported in Windows. The core has the
function that would permit writing a diff from scratch, and it be nice
for someone to do this. However, Eclipse offers much better diff support, so
writing a diff is not an urgent task.

We use 'find' since java.io.File doesn't know about executable attribute and
link files. Since these are found only in Unix, the 'find' command is invoked
via Exec. We could add flags to allow user to request "Java file" mode as you suggest.

> 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.
> 

Yes, we should support Sun's JDK if possible.
I have opened task "sun jdk", Bugzilla 28787, on this issue.

thanks (again),
dave

-- 
Dave Shields, IBM Research, shields@xxxxxxxxxxxxxx.