In a production application, we encountered an issue of significant lock contention in Hibernate Validator 5.4.2 (included in the latest DropWizard framework). The stack traces of affected threads looked like:
When an application received an initial burst of traffic, a significant number of threads were locked up with the same stack trace (in one instance, 962 threads) until the application became unavailable.
The classmate library had a similar report of this issue in GitHub (https://github.com/FasterXML/java-classmate/issues/40). As part of this issue, the maintainer of classmate introduced a new ConcurrentTypeCache TypeResolver in 1.4.0 which switches the underlying cache from using a synchronized LinkedHashMap to a ConcurrentHashMap.
Unfortunately, there doesn't appear to be any way to modify the Hibernate TypeResolver (https://github.com/hibernate/hibernate-validator/blob/45e7fdf275989e5c022d4a6bd3a8ad6a8fb88dfe/engine/src/main/java/org/hibernate/validator/internal/util/TypeResolutionHelper.java#L21) when instantiating a Hibernate validator. Would it be possible to consider one of the following improvements to the Hibernate Validator API to fix this contention?
Upgrade to classmate 1.4.0 and switch from the default TypeResolver (which uses LinkedHashMap) to an appropriately sized ConcurrentTypeCache TypeResolver. Note: The ConcurrentTypeCache is not an LRU cache so there is an expensive clearing of the cache when it reaches capacity - depending on the application, it might be necessary to tune this size in order to avoid rebuilding the cache.
Provide a means via an API for a consumer of Hibernate Validator to override the default TypeResolver or TypeResolutionHelper to tune this cache as needed.