RFR 8143302: javax/net/ssl/Stapling/SSLSocketWithStapling.java fails intermittently: Server died

Hi all, This fixes a couple problems. The first is a file descriptor leak in the SSLSocketWithStapling test. The second is a thread exhaustion issue that can happen when many many (> 1000) SSLContext objects are created with StatusResponseManagers. I think this is a pretty far flung edge

Re: RFR 8130302: jarsigner and keytool -providerClass needs be re-examined for modules

I will take a look tomorrow. Thanks, Valerie On 6/28/2016 6:09 PM, Wang Weijun wrote: Ping again to security-dev. Anyone can approve it? The latest webrev is at http://cr.openjdk.java.net/~weijun/8130302/webrev.06 Change from webrev.05 [1] is tiny. Thanks Max [1]

Re: RFR 8130302: jarsigner and keytool -providerClass needs be re-examined for modules

Ping again to security-dev. Anyone can approve it? The latest webrev is at http://cr.openjdk.java.net/~weijun/8130302/webrev.06 Change from webrev.05 [1] is tiny. Thanks Max [1] http://cr.openjdk.java.net/~weijun/8130302/webrev.06/interdiff.patch.html > On Jun 16, 2016, at 9:33 AM, Wang

Re: RFR: 8158670: Fix @modules in java/lang/SecurityManager/CheckSecurityProvider.java

One of the purpose of this test is to test the ordering (see the initial bug which this test is for: JDK-6997010). The original test already detects the OS and will skip certain providers accordingly. Instead of splitting the test into multiple platform-specific tests, maybe we can keep the

Re: RFR: 8158670: Fix @modules in java/lang/SecurityManager/CheckSecurityProvider.java

Copyrights fixed in place. Thank you, Mandy. Shura > On Jun 27, 2016, at 12:27 PM, Mandy Chung wrote: > > I’m including security-dev which would be a better list to review this test > fix. > > Valerie, > Does this test have to be order-sensitive? I think this test

RFR: 8154015 Apply algorithm constraints to timestamped code

Hi, I need a review of the below code. It's a continuation of the previous certpath related changes. Additional constraints checking on timestamped jars being checked by the deploy code http://cr.openjdk.java.net/~ascarpino/8154015/webrev.01/ thanks Tony

Re: [9] RFR: 8159416: javax/net/ssl/DTLS/CipherSuite.java failed on timeout

On 6/28/2016 1:02 PM, Artem Smotrakov wrote: Hi Xuelei, Even if the tests keep using UDP to transfer data, they may not be realistic since they run on local host. UDP implementation is based on functions provided by OS. If I remember correctly, Solaris may do some optimizations for localhost

Re: [9] RFR: 8159416: javax/net/ssl/DTLS/CipherSuite.java failed on timeout

Hi Xuelei, Even if the tests keep using UDP to transfer data, they may not be realistic since they run on local host. UDP implementation is based on functions provided by OS. If I remember correctly, Solaris may do some optimizations for localhost connections, so that no real networking