BlockHound | Java agent to detect blocking calls from non-blocking threads | Monitoring library

Sorry, just realized that the flatMap in parallel flux call was actually like below

Explaining the error

Based on the output you included, it looks like you're using buildpacks (i.e. ./mvnw spring-boot:build-image or ./gradlew bootBuildImage or pack build).

In that case, you can set the env variable JAVA_TOOL_OPTIONS with -XX:ActiveProcessorCount=x to override the default calculation. The default calculation will pull the total number of processors (as reported by Go's runtime.NumCPU() function).

Side note. What you are asking seems reasonable, so I opened an issue to see if we can enable it to detect the limited CPU count.

Nothing is wrong here, you've just hit a corner case.

Mono.just() is a rather special kind of Mono in more ways than one (which is why I despair at its use in so many simple "getting started" style examples, but I digress) - since you're literally just wrapping a value inside a dummy publisher, it never needs to block in order to return its value, even if you call the block method. The method name might imply you're blocking, but you can trivially verify from the source code that it just returns a value. There's therefore no blocking operation occurring, and so nothing for Blockhound to complain about.

If you were to add another operator in the mix, even if it has no real-world effect:

String a = Mono.just("block").cache().block();

...then you'll see Blockhound start complaining, as you're no longer directly using the special case of MonoJust.

Blockhound is doing exactly what it should here, the issue is that you're (very understandably) expecting something to block which doesn't.

The BOM dependency should go in the section

Official response from Datastax team:

The error is happening when Spring is building the application context, which happens when the application starts. Blocking calls are usually allowed during this phase, even for reactive / non-blocking applications – otherwise, your application would be totally unable to read a config file, for instance – since this is a blocking call.

Actively working on JAVA-2449 right now. I will change Uuids.random() to use non-blocking stuff.

According to your gist, BlockHound is detecting java.io.FileInputStream.readBytes(..) as blocking deep within the SSL handshake.

This problem has been reported in https://github.com/reactor/reactor-netty/issues/939 and appears to be resolved in the latest releases.