Thanks Paul, I'll add a comment.
On 6/25/2018 2:26 PM, Paul Sandoz wrote:
On Jun 25, 2018, at 11:08 AM, Roger Riggs <roger.ri...@oracle.com
<mailto:roger.ri...@oracle.com>> wrote:
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.
Ah yes, i see now. Perhaps add a comment or something in the summary
stating that failure will result in a time out? (No need for another
review).
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.
Ok.
Paul.
