My understanding was that pages which are inherently non blocking could be blocked due to the use of shared threadpools and by default leveraging the same execution contexts.
I would love to understand if this is a problem in practice, or if there are other practical implications.
It's definitely a real, common problem, but I think the article obscures it a bit. Blocking I/O operations using the Akka dispatcher will block that thread while the command executes. Doing this too often will cause all the akka threads to be blocked, stopping the dispatcher from processing more events. Therefore, one should avoid performing blocking operations on akka threads.
In my experience, one of two things will happen in practice:
1) You use an asynchronous library for I/O calls, which will maintain its own threadpool. This is no problem, because the I/O threadpool is independent from the akka theadpool.
2) You want to use a synchronous library that performs I/O operations using the caller's thread. If you must do this, you should use a separate threadpool (ExecutionContext).
Comments
My understanding was that pages which are inherently non blocking could be blocked due to the use of shared threadpools and by default leveraging the same execution contexts.
I would love to understand if this is a problem in practice, or if there are other practical implications.
It's definitely a real, common problem, but I think the article obscures it a bit. Blocking I/O operations using the Akka dispatcher will block that thread while the command executes. Doing this too often will cause all the akka threads to be blocked, stopping the dispatcher from processing more events. Therefore, one should avoid performing blocking operations on akka threads.
In my experience, one of two things will happen in practice:
1) You use an asynchronous library for I/O calls, which will maintain its own threadpool. This is no problem, because the I/O threadpool is independent from the akka theadpool.
2) You want to use a synchronous library that performs I/O operations using the caller's thread. If you must do this, you should use a separate threadpool (ExecutionContext).