Thoughts on possible options to JDK-8027598
Chris Hegarty
chris.hegarty at oracle.com
Wed Nov 20 11:54:17 UTC 2013
On 20/11/13 01:07, Xuelei Fan wrote:
> On 11/20/2013 8:19 AM, Rajan Halade wrote:
>> I am working towards fixing JDK-8027598
>> <https://bugs.openjdk.java.net/browse/JDK-8027598>, there are multiple
>> options available here and would appreciate your thoughts on this. It
>> was filed to address the issue at large reported inJDK-8027526
>> <https://bugs.openjdk.java.net/browse/JDK-8027526>.
>>
>> Problem - When a regression test is run in agentvm mode and alters
>> security providers, it can cause adverse effects on next tests executed
>> in the batch. We have been batteling with few intermittent failures
>> which are caused by scenario like this so I think it is important to
>> have this fix.
>>
>> 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.
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.
-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
>>
>>
>
More information about the security-dev
mailing list