Hi Paul,
Updated the webrev in place:
http://cr.openjdk.java.net/~rriggs/webrev-fd-count-wrong-8205547/
On 6/25/2018 1:41 PM, Paul Sandoz wrote:
Hi Roger,
Are you missing the throwing of an exception when the fdCount != fdCount0? (and
relatedly i could not tell if the print statements were for temporary debugging
and you intended to remove them)
That condition needed to be removed, the number of open file descriptors
changes unpredictably
during the test. The check for the reclamation of the 'FileDescriptor'
and 'closer' replaces
the simple count of open file descriptors.
In one case, I spotted a socket that showed up as open during the test
(but the code does not use sockets).
The failures have only been seen using mach5 and are not otherwise
reproducible.
I retained and improved the debugging information with some aspiration
to determine
what file descriptor was appearing or disappearing.
Since you check before hand for support of UnixOperatingSystemMXBean there
appears no need for the method getFdCount can you can reuse the local variable
unixMxBean. (If the check fails it suggests the @requires is incorrect,
implying the test should fail.)
Right, I updated this case to look like the other
java/io/FileXXXStream/UnreferencedXXXClosesFd tests
that did not have the @requires or the pretest.
The direct use of unixMxBean is fine; I reverted the addition of
getFdCount().
I'll keep the instanceofUnixOperatingSystemMXBean as belt and suspenders.
Thanks, Roger
Paul.
On Jun 25, 2018, at 8:24 AM, Roger Riggs <roger.ri...@oracle.com> wrote:
Please review a test improvement to avoid unexpected file opens/closes during
the file channel CleanerTest.
The test now follows the pattern of the other
java/io/File*/UnreferencedXXXClosesFd tests by waiting
for the cleaner and file descriptors to be reclaimed by GC.
Webrev:
http://cr.openjdk.java.net/~rriggs/webrev-fd-count-wrong-8205547/
Thanks, Roger
