JDK-6432000 : Static certificate cache can limit scalability
  • Type: Bug
  • Component: security-libs
  • Sub-Component: java.security
  • Affected Version: 6
  • Priority: P2
  • Status: Resolved
  • Resolution: Not an Issue
  • OS: generic
  • CPU: generic
  • Submitted: 2006-05-31
  • Updated: 2017-07-17
  • Resolved: 2017-07-17
Related Reports
Duplicate :  
Duplicate :  
Relates :  
A customer at JavaOne reported that the certificate cache in sun.security.provider.X509Factory can limit scalability if there are many threads parsing many certificates concurrently. The reason is that the cache is static and uses a synchronized block for mutual exclusion. I have not had a chance to reproduce this scalability issue myself, but would expect it to only be measurable under rare circumstances.

The fix is more complicated than simply replacing HashMap with ConcurrentHashMap because the implementation uses a LinkedHashMap to implement LRU replacement and LinkedHashMap has no concurrent equivalent. ConcurrentHashMap does not specify iteration order, so just dropping it in would result in random replacement instead of LRU replacement, which is almost certainly not acceptable.

The possible options include:

 . Dolphin may include a java.util.Cache class/framework, which would hopefully address all our requirements (including scalability) and could be used to replace the existing implementation (sun.security.util.Cache)

 . it may be possible to tune the current implementation somewhat, e.g. by using ReadWriteLocks, shortening the critical sections, expunging a batch of elements at once in case of cache overflow, etc.

 . give up on LRU and implement FIFO instead, using something like ConcurrentHashMap in combination with ConcurrentLinkedQueue.

No longer significant since JDK-8129988 is fixed,

I would look into whether a ConcurrentSkipListMap might be an adequate replacement. This allows you to define your own Comparator to control the order.