The BlockingProcess actor's dispatcher was leveraged for use by various IO operations within it. For some undiscovered reason, this led the BlockingProcess to become blocked at around the minimum number of threads per the core setting of its ThreadPoolExecutor (21).
I was able to create a new test that started up 100 processes, and therefore 300 threads on a dedicated dispatcher. Without the changes to the BlockingProcess actor i.e. with the actor sharing its TPE with the stdio stream sources and sinks, the test often failed and hung. With the changes where the TPE is dedicated to the IO, and the BlockingProcess actor resides on the default dispatcher, I was unable to reproduce the issue.
In addition, having a dispatcher dedicated to the actor's IO feels correct from a design standpoint.
Finally, the problem of seeing that threads were blocked in the manner described here was observed at a ConductR customer's site. ConductR uses the BlockingProcess actor to manage its bundle processes. By applying these changes I'm optimistic that the customer issue will be resolved.
markusjura
commented
8 years ago
The BlockingProcess actor's dispatcher was leveraged for use by various IO operations within it. For some undiscovered reason, this led the BlockingProcess to become blocked at around the minimum number of threads per the core setting of its ThreadPoolExecutor (21).
I was able to create a new test that started up 100 processes, and therefore 300 threads on a dedicated dispatcher. Without the changes to the BlockingProcess actor i.e. with the actor sharing its TPE with the stdio stream sources and sinks, the test often failed and hung. With the changes where the TPE is dedicated to the IO, and the BlockingProcess actor resides on the default dispatcher, I was unable to reproduce the issue.
In addition, having a dispatcher dedicated to the actor's IO feels correct from a design standpoint.
Finally, the problem of seeing that threads were blocked in the manner described here was observed at a ConductR customer's site. ConductR uses the BlockingProcess actor to manage its bundle processes. By applying these changes I'm optimistic that the customer issue will be resolved.