-
Bug
-
Resolution: Not an Issue
-
P2
-
None
-
6
-
generic
-
generic
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.
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.
- duplicates
-
JDK-6440092 X509Factory caching
- Closed
-
JDK-8130025 Tomcat enter stuck status, one thread hold the lock, and all others are blocked
- Closed
- relates to
-
JDK-8129988 JSSE should create a single instance of the cacerts KeyStore
- Closed