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

[Paul Sandoz]

> On Jun 25, 2018, at 11:08 AM, Roger Riggs <Roger.Riggs at 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.