On 11/20/2013 11:35 PM, Rajan Halade wrote:
....
Possible approaches -
1. Enhance JTREG - This option would require change in jtreg to
store/restore security providers when run in agentvm mode.
If I am correct, JTREG has support provider cleanup already. But the
question is even JTREG reset the providers, it still cannot ensure next
test won't be impacted because in some circumstances JDK may need to
cache something which depends on previous providers. Still need to
analysis the test case by case.
Right, any static or cached data may be invalid, and this will require
careful changes to the JRE itself.
Pardon my ignorance - if I gather correctly then ProvidersSnapshot
library also doesn't sandbox effects completely.
FYI. I am not part of the security team, and someone from the security
group should ultimately have to agree/disagree, but we have similar
issues in other parts of the platform. I don't know the specifics of the
code here so it may, or may not, be an issue.
If any part of the security framework stores values in static fields,
that is dependent on the security providers, then when the providers
change this static value may be incorrect.
We encounter this from time to time with system properties. E.g. JDK
HTTP Client code reads system property and stores in static field, JDK
HTTP Client will never never re-read the property as it believes it will
not change. Having jtreg reset/clean certain system properties will not
help in this case.
If there are not too many of these tests, I don't think that
explicitly marking them othervm will hurt too much. And making them
reliable will reduce greatly the amount of time spent head scratching
chasing intermittent failures.
I agree with you, we need to consider using othervm mode. There are ~66
(1% of all reg tests) such tests which are run in agentvm, don't use
ProvidersSnapshot library, and are modifying providers. I think its safe
to go with othervm option, let me know.
IMHO, this is the right way to go here.
-Chris.
- Rajan
-Chris.
Xuelei
2. Update impacting tests to run in othervm - simple change but may
slow
down batch execution slightly.
3. Update each test to use library
java/security/KeyPairGenerator/Failover.java like done in
java/security/Provider tests - another easy change and tests would
continue to run agentvm but would have added overhead of restoring
providers.
We will continue to pursue option 1 but many not be possible. Option
2 &
3 above are equally good and are debatable so would like your thoughts
on it.
Thanks,
Rajan