Max, if we can get an agree, would you please update the Makefile to
run JSSE in othervm mode  in your fix? So that we don't have to fill
a new CR.

There are two ways to do this:

1. Add "@run main/othervm" to all JSSE tests. This means a lot of code changes, but I can automate it.

2. Create new test set for JSSE. This is what I had done before in

   http://cr.openjdk.java.net/~weijun/7055363/webrev.00/

many changes to Makefile, jprt.properties and jprt.properties in the parent repo.

I'd choose #1. What's your opinion?

BTW, you mentioned HTTPS and JNDI codes. If they are not inside sun/security, I won't touch them this time. Also, at least I know tests inside test/closed/sun/security/ssl/java/security/KeyStore can run in samevm. Can you give a whitelist?

Thanks
Max


On 08/04/2011 12:05 PM, Xuelei Fan wrote:
- JSSE tests, Xuelei is working on them
It may be a bad news for the purpose to quicken the testing run
time. Most of the JSSE test may not be able to under samevm/agentvm
mode.

1. JSSE does not support dynamic system properties For performance
tuning and synchronization, JSSE does not support dynamic system
properties of: "java.protocol.handler.pkgs" "javax.net.ssl.keyStore"
"javax.net.ssl.keyStorePassword" "javax.net.ssl.trustStore"
"javax.net.ssl.trustStorePassword"

The JSSE default implementation will use these properties when
initializing the static objects, and then any changes to these
properties will be ignored in the same VM.

There are around 90 of all 170+ JSSE regression tests depends on
system properties.

2. JSSE caches TLS sessions, as will result in unexpected reuse of
TLS sessions in samevm/agentvm mode. There are a lot of tests using
the default SSL/TLS context, which will the same TLS session cache.

There are only a very very few tests could be updated to run in
samevm mode. Because samevm-safe in JSSE tests will result in
unnecessary complex, and the performance improvement is very little,
I would suggest tun all JSSE tests at othervm mode.

What do you think?

Max, if we can get an agree, would you please update the Makefile to
run JSSE in othervm mode  in your fix? So that we don't have to fill
a new CR.

Thanks, Xuelei

On 8/2/2011 3:02 PM, Weijun Wang wrote:
Hi All

http://cr.openjdk.java.net/~weijun/7055363/webrev.01/

*Attention*: please note that the jtreg mode for jdk_security3 is
still RunOthervmBatch. Xuelei is now working on the JSSE tests.
Once he is ready, he will change the mode to RunSamevmBatch.

The code changes:

* Still included in test/ProblemList.txt

- JSSE tests, Xuelei is working on them - ec tests on solaris-i586,
they fail even if run standalone

* PKCS11/EC tests:

- New Providers.setAt, to ensure provider is added to desired
position: test/sun/security/pkcs11/ec/*

- PKCS11Test.safeReload, to ensure shared library can be loaded
again: test/sun/security/pkcs11/PKCS11Test.java
test/sun/security/pkcs11/SecmodTest.java

- Test using config files need to run in othervm:
test/sun/security/pkcs11/Secmod/* test/sun/security/pkcs11/fips/*

- Restoring provider lists: test/sun/security/ec/TestEC.java
test/sun/security/pkcs11/PKCS11Test.java

* Try-with-resources updates:

- test/com/sun/security/auth/login/ConfigFile/IllegalURL.java -
test/sun/security/pkcs12/PKCS12SameKeyId.java -
test/sun/security/tools/keytool/StartDateTest.java

* Other tests still need to be in -othervm:

Using special policy file:
test/sun/security/provider/PolicyFile/Comparator.java AlgorithmId
static field oidTable initialization:
test/sun/security/x509/AlgorithmId/ExtensibleAlgorithmId.java

* JAAS configuration restore:

-
test/javax/security/auth/login/LoginContext/ResetConfigModule.java

* Use "localhost" as hostname, to make name resolution fast

- test/sun/security/jgss/spnego/NoSpnegoAsDefMech.java


After these changes, JPRT test run (with RunSamevmBatch and no
JSSE tests) shows most tests are OK. There are still intermittent
failures which are PKCS11/EC provider related.

Thanks Max

Reply via email to