RFR 8205547 : FileChannel/CleanerTest.java fails due to expected FD count

[Roger Riggs]

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