In the default config of a jvm-sdk app we use the default dispatcher as internal dispatcher to optimize for low resource usage, if a user writes a very blocking application this means it is quite easy to starve the entire Kalix node (I think that is what is going on in https://discuss.kalix.io/t/multiple-requests-at-the-same-time-multi-threading-concern/106/9 which does a Thread.sleep(6000) and cannot observe parallel request processing)
We should have a section in the JVM SDK docs talking about how the default config is for non-blocking and showing how to tune the dispatcher for blocking logic through config.
In the default config of a jvm-sdk app we use the default dispatcher as internal dispatcher to optimize for low resource usage, if a user writes a very blocking application this means it is quite easy to starve the entire Kalix node (I think that is what is going on in https://discuss.kalix.io/t/multiple-requests-at-the-same-time-multi-threading-concern/106/9 which does a
Thread.sleep(6000)
and cannot observe parallel request processing)We should have a section in the JVM SDK docs talking about how the default config is for non-blocking and showing how to tune the dispatcher for blocking logic through config.