RFR 8065076/9, test/java/net/SocketPermission/SocketPermissionTest.java failed intermittently

Felix Yang felix.yang at oracle.com
Thu Jan 21 22:55:30 UTC 2016

Hi Chris,
     your fix is cool. I will assign the bug to you:)
     a comment on this fix. The test changed system SecurityManager and it is not executed with othervm mode. I think you need to rollback the change after test. Otherwise it may affect other tests.

> On Jan 20, 2016, at 12:45 PM, Chris Hegarty <chris.hegarty at oracle.com> wrote:
> On 20 Jan 2016, at 06:36, Chris Hegarty <chris.hegarty at oracle.com <mailto:chris.hegarty at oracle.com>> wrote:
>> Felix,
>> On 14 Jan 2016, at 06:07, Felix Yang <felix.yang at oracle.com> wrote:
>>> Hi all,
>>>  please review the fix for test/java/net/SocketPermission/SocketPermissionTest.java, which fails frequently with "java.net.BindException: Address already in use".
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8065076
>>> Webrev: http://cr.openjdk.java.net/~xiaofeya/8065076/webrev.00
>> My preference is to avoid getFreePort. It is problematic and I believe just obfuscates
>> the intermittent failures further.
>> In many of the test scenarios the “listening” socket can be created before the specific
>> access control context and associated permission are created.
>> I’ll see if I can get some time to try this out.
> I spent a little time on this today. I basically rewrote the test, but kept the 
> same test scenarios. The use of data providers was cute, but not workable
> since there is no common supertype for the socket classes. I decided to 
> just expand out the test cases manually. This will give the same test
> coverage, but should be stable since it creates the sockets first, on an 
> ephemeral port, and then constructs the permissions appropriately given
> that port.
> http://cr.openjdk.java.net/~chegar/8065076/ <http://cr.openjdk.java.net/~chegar/8065076/>
> The webrev diffs are almost useless, just review the new file, and compare
> test scenarios against the what is in the old file.
> -Chris.

More information about the core-libs-dev mailing list