> On Jun 25, 2018, at 11:08 AM, Roger Riggs <roger.ri...@oracle.com> wrote:
>
> Hi Paul,
>
> Updated the webrev in place:
> http://cr.openjdk.java.net/~rriggs/webrev-fd-count-wrong-8205547/
> <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.
