jackson blocking calls reported by BlockHound

[krysiuda]

Hi,

We have a webflux/reactor application running in production, after recent JVM upgrade we've noticed new exceptions thrown by BlockHound, for a blocking call in com.fasterxml.jackson.databind.deser.DeserializerCache (part of jackson-databind).

While taking a look at the jackson implementation I notice:

    /**
     * We hold an explicit lock while creating deserializers to avoid creating duplicates.
     * Guards {@link #_incompleteDeserializers}.
     *
     * @since 2.17
     */
    private final ReentrantLock _incompleteDeserializersLock = new ReentrantLock();

so some of the initialization will definitely block on the ReentrantLock.

The dependency tree leading to jackson-databind starts from:
spring-boot-starter-data-elasticsearch->spring-data-elasticsearch->jackson-databind
AND:
spring-boot-starter-webflux->spring-boot-starter-json->jackson-databind
it's a transient dependency, we don't require it directly.

I believe since jackson-databind uses a ReentrantLock, an whitelist exception should be added for BlockHound, and since jackson-databind is required for spring-boot-starter-webflux it seems reasonable to make it part of webflux starter.

[bclozel]

Thanks for getting in touch, but Spring Framework only manages exceptions for its own classes, not all libraries that Spring support in general. You can reach out to the blockhound project for more help.