-
Notifications
You must be signed in to change notification settings - Fork 76
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
AkkaStream & PekkoStream usage can lead to threads blocked/waiting #627
Comments
Obviously, if you see any better way of fixing this, please say it :) I'm not super fan of |
Either Akka or Pekko, if you needs execution of blocking function to be isolated, needs to use a separe dispatcher (not the main Play one). |
Sure but how could I do it in this scenario then? I may be missing something obvious but the blocking code is out of my control. If As a client of the library (Anorm), I'm only giving it a SQL query to execute in streaming over a |
As a client of the Akka or Pekko, you provide a Materializer, based on a dispatcher, which must but isolated. |
Context
We use Anorm with PekkoStream (previously AkkaStream) in a Play Framework application. Our usage is pretty standard with the exception that the requests we do with Anorm are to a database that can take several seconds (or even more sometimes) to start answering results.
In this situation, we noticed that all "default" threads can become blocked and thus the Play application becomes irresponsive to any request (including a healthcheck request that is absolutely unrelated and just answers
OK
without doing anything else).Details
Our usage
Just to highlight that we're not doing anything custom, minimized code:
Observations
A thread dump during a period where the application is irresponsive shows threads being waiting/hanging in the
preStart
of the stream:Relevant code in Anorm:
anorm/pekko/src/main/scala/anorm/PekkoStream.scala
Lines 123 to 130 in 7501f26
Workaround
We've been able to fix the issue on our side by explicitly wrapping the
preStart
code in ascala.concurrent.blocking
block.(This requires that we "fork" this class in our own code.)
This has for consequences that the thread pool of Pekko actors can grow to still be able to accept non-blocking code. The threads hanging for the database are not blocking anymore other requests.
Now the question is: should it be the default behavior? As Anorm and JDBC drivers are blocking by default, shouldn't the
preStart
be robust so that if it blocks, it doesn't affect the Pekko actors threads? Would there be any downside in wrapping this code inblocking
even if it isn't actually blocking?If it makes sense to you, I'll be happy to open the PR :)
The text was updated successfully, but these errors were encountered: