JDK-8185620 : MSCAPI test leaves too many entries in keystore
  • Type: Bug
  • Component: security-libs
  • Sub-Component: java.security
  • Affected Version: 10
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2017-08-01
  • Updated: 2018-05-24
  • Resolved: 2017-08-15
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 10
10 b20Fixed
Related Reports
Relates :  
Description
It seems that MSCAPI related tests leave too many entries in keystore, thus may cause mscapi/keytool/keystore related tests runs very slow.

One example: sun/security/mscapi/AccessKeyStore.java

It normally should take less than 2 seconds, but at the box on which many runs have been done, it took 36 seconds. From the .jtr, there are too much keystore entries:

----------System.out:(3394/85623)----------
SunMSCAPI provider classname is sun.security.mscapi.SunMSCAPI
[0]
    anything (1960) [key-entry]

...

-------------------------------------------------
[12215]
    anything (576) [key-entry]

(while for the machine at which test just took less than 2 seconds to complete, the last key-entry is [49])

Comments
Test sun/security/mscapi/SmallPrimeExponentP.java set many entries into Windows native keystore Windows-MY, but it doesn't delete the entries. And Windows native keystores support duplicate alias names. Beside fixing this test issue, it also should delete such "anything" keystore entries from that testing machine. number=`keytool -list -storetype Windows-MY | grep "anything" | wc -l` echo $number for ((i=0; i<$number; i++)); do keytool -delete -storetype Windows-MY -alias "anything" done
04-08-2017

Thank you Amy for reporting and looking into this. That's a good question how we could work around it, but unfortunately I don't have an answer at the moment. I think the best way is to look for tests which adds entries to the keystore, and do cleanup in a "finally" block.
02-08-2017

Is it reproducible standalone (without same binary run) on the machine where it was seen? I don't see that AccessKeyStore adds any new entry to the keystore, but other MSCAPI tests probably do. If a test adds new entries to the keystore, it might be better to remove them in a "finally" block. So, I am adding 'noreg-self' for now. Although I am not sure if ~500 entries can be considered as a large amount or not, I am wondering if security-libs should be able to handle them faster. It would be good to figure out what exactly is going slow.
01-08-2017