gnu/testlet/java/nio/channels/FileChannel/manyopen.java broken

gnu/testlet/java/nio/channels/FileChannel/manyopen.java broken

[Noa Resare]

gnu/testlet/java/nio/channels/FileChannel/manyopen.java tries to open
1024 * 3 files and signals failure if that fails.

I don't think it can be considered an error if this fails, especially
since many popular operating systems limit the number open files that a
single process can have:

Here is the output of "ulimit -n" on some boxes I have access to:

OpenBSD 3.4 x86: 64
Solaris 9 sparc: 256
Linux (debian 2.2 x86/suse 8 AMD64/Fedora core 1/2/3) : 1024
FreeBSD 4.10-BETA: 7322
NetBSD 1.6.1: 64
OSX 10.2: 256

Since the test doesn't actually test for anything other than the ability
to open many files and the extent of that ability isn't specified in any
spec that I'm aware of I suggest that we remove the test.

/noa

Re: gnu/testlet/java/nio/channels/FileChannel/manyopen.java broken

[Stephen Crawley]

noa@resare.com said:
> Since the test doesn't actually test for anything other than the
> ability to open many files and the extent of that ability isn't
> specified in any spec that I'm aware of I suggest that we remove the
> test. 

Agreed.  It should be deleted.

This testcase previously used to also (indirectly) check that orphaned file
handles were closed by garbage collection finalization.  However, this
was done by explicitly calling System.gc(), and thus was even more broken
that the current version of the testcase.

-- Steve

Re: gnu/testlet/java/nio/channels/FileChannel/manyopen.java broken

[Mark Wielaard]

[-- Attachment #1: Type: text/plain, Size: 1836 bytes --]

Hi,

On Fri, 2004-10-08 at 08:47, Stephen Crawley wrote:
> noa@resare.com said:
> > Since the test doesn't actually test for anything other than the
> > ability to open many files and the extent of that ability isn't
> > specified in any spec that I'm aware of I suggest that we remove the
> > test. 
> 
> Agreed.  It should be deleted.
> 
> This testcase previously used to also (indirectly) check that orphaned file
> handles were closed by garbage collection finalization.  However, this
> was done by explicitly calling System.gc(), and thus was even more broken
> that the current version of the testcase.

As the person that wrote this test let me explain why I wrote it and
what I think should be tested.

We had a problem with real programs that open lots of files quickly
(gjdoc does this for example, a jar tool or a webserver might be another
good example) and don't explicitly close these files, but let the
file/stream just get garbage collected since the program structure
doesn't explicitly define a "owner" for the file/stream object (which
isn't that uncommon since that is what you normally do with random
allocated objects, long life the garbage collector!).

What I think should be tested is whether a program can open lots of
files. And that the systems notices that stale file handle resources can
be removed so that a program can keep opening files if needed. (As long
as there are no large number of life file handles open at the same
time.)

Since I have seen multiple systems get this wrong in various ways I want
to have an explicit test for this situation. It might be that this test
does not simulate a real world program correctly, so if there are
alternatives I would like to hear them instead of just deleting the test
since some systems fail it.

Cheers,

Mark

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: gnu/testlet/java/nio/channels/FileChannel/manyopen.java broken

[Noa Resare]

On fre, 2004-10-08 at 12:05 +0200, Mark Wielaard wrote:
> Hi,
> What I think should be tested is whether a program can open lots of
> files. And that the systems notices that stale file handle resources can
> be removed so that a program can keep opening files if needed. (As long
> as there are no large number of life file handles open at the same
> time.)
> 
> Since I have seen multiple systems get this wrong in various ways I want
> to have an explicit test for this situation. It might be that this test
> does not simulate a real world program correctly, so if there are
> alternatives I would like to hear them instead of just deleting the test
> since some systems fail it.

Ah, now I understand. Thanks for the explanation.

/noa

Re: gnu/testlet/java/nio/channels/FileChannel/manyopen.java broken

[Thomas Zander]

On Friday 08 October 2004 12:05, Mark Wielaard wrote:
> What I think should be tested is whether a program can open lots of
> files. And that the systems notices that stale file handle resources can
> be removed so that a program can keep opening files if needed. (As long
> as there are no large number of life file handles open at the same
> time.)

So; what you want tested if 
a) File has finalize method
b) that method actually closes the filehandle
c) the GC / Finalizer / GC (in that order) is called early enough and often 
enough to ensure not only we don't have a OutOfMem, but also that we don't 
get an out-of-filehandles problem.

IMO that should give you 3 seperate tests with very different things; your 
test (from the description, I did not read the test itself) seems to have 
taken the black-box-approuch which is most of the time wrong for unit 
tests..

> Since I have seen multiple systems get this wrong in various ways I want
> to have an explicit test for this situation. It might be that this test
> does not simulate a real world program correctly, so if there are
> alternatives I would like to hear them instead of just deleting the test
> since some systems fail it.

Isn't creating an 'any' object with a finalizer and doing the same things, 
but keeping a counter of how often finalize is called verses how many 
objects are present going to test this problem much much simpler?

Just a thought...
-- 
Thomas

Re: gnu/testlet/java/nio/channels/FileChannel/manyopen.java broken

[Stephen Crawley]

Mark Wielaard <mark@klomp.org> wrote:
> We had a problem with real programs that open lots of files quickly
> (gjdoc does this for example, a jar tool or a webserver might be another
> good example) and don't explicitly close these files, but let the
> file/stream just get garbage collected since the program structure
> doesn't explicitly define a "owner" for the file/stream object (which
> isn't that uncommon since that is what you normally do with random
> allocated objects, long life the garbage collector!).

Java programs that rely on the GC to find / close file handles are
non-portable and (IMO) broken.  A portable program cannot depend on
the GC running soon enough to get around a problem with running
out of file descriptors.  Indeed, it cannot even reliably cause the
VM to run the garbage collector, because the VM is allowed to treat 
a call to java.lang.System.gc() as a "hint" ... and ignore it.

[For the record, Kissme is currently implemented to only respect 
calls to java.lang.System.gc() when it is launched with the "-gc"
command line option.]

> What I think should be tested is whether a program can open lots of
> files. And that the systems notices that stale file handle resources can
> be removed so that a program can keep opening files if needed. (As long
> as there are no large number of life file handles open at the same
> time.)

The trouble is that you cannot write a portable / reliable testcase for 
this.  Even if you could, I do not believe that a Java VM should be 
required to be able to run programs that leak file descriptors like this.

> Since I have seen multiple systems get this wrong in various ways I want
> to have an explicit test for this situation. It might be that this test
> does not simulate a real world program correctly, so if there are
> alternatives I would like to hear them instead of just deleting the test
> since some systems fail it.

I think the solution is to test for behaviour that is not required by
the Java 'specification' in a VM-specific test suite ... not in Mauve.

-- Steve

RE: gnu/testlet/java/nio/channels/FileChannel/manyopen.java broken

[Jeroen Frijters]

Stephen Crawley wrote:
> Java programs that rely on the GC to find / close file handles are
> non-portable and (IMO) broken.  A portable program cannot depend on
> the GC running soon enough to get around a problem with running
> out of file descriptors.

While I agree with your general point (and that this test shouldn't be
in Mauve), I would like to add a small footnote:

The nio memory mapped file API *requires* you to rely on the GC to close
the files.

Personally, I happen to think that the API is broken because of this,
but as of 1.4 (haven't looked at 1.5 yet) this is the sad reality.

Regards,
Jeroen