Reputation: 11091
I add this to two places in my code
Flux.empty()
.collectList()
.block();
In one case IntelliJ highlights .block()
with error message Inappropriate blocking method call
. In the other place it's ok.
In Settings -> Inspections
I see that this can be because in this fragment thread should not be blocked.
Reports thread-blocking method calls found in a code fragment where a thread should not be blocked (e.g. Reactive frameworks, Kotlin coroutines)
In what places thread should not be blocked? I know that we have to avoid blocking calls but I'm doing a migration from reactive to non-reactive and need this blocking as a temporary workaround.
Upvotes: 3
Views: 7974
Reputation: 72379
In what places thread should not be blocked? I know that we have to avoid blocking calls but I'm doing a migration from reactive to non-reactive and need this blocking as a temporary workaround.
The absolute no-no is on a Netty event loop thread, as there's deliberately only a few of those threads, and they're designed to be always busy (never blocking) so as to achieve maximum throughput. This is probably what IntelliJ is complaining about. (Schedulers.single
and Schedulers.parallel
are the relevant reactor schedulers here.)
Blocking on another thread is potentially ok, so long as you're aware that's happening and understand the ramifications for doing so. The usual places you'll deliberately block in a migration such as this is either in a separate threadpool (one you've designated for these blocking tasks specifically), or the built in reactor Schedulers.elastic
or Schedulers.boundedElastic
pools, which are designed for this sort of purpose.
Upvotes: 4