New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Reverse actor stopping order (was: Check that actor is still runable after message has been recieved.) #8
Comments
Hmm, problem could also be due to simple thread switching, as I'm testing with |
«The actor will finish processing any messages already in its queue before stopping. It may not be restarted.» - so I guess this is intended behavior. So, I guess my new question is, how |
When using By using To shut down actors in a sequence that takes dependencies into consideration, avoiding the case where living-soon-to-stop actors depends on stopped actors, I think we would need some kind of supervision hierarchy. If we're to go that way, we should probably have a second look at Erlang and/or Akka to see how this can be solved once and for all. |
I was thinking about rewriting mopidy's stop_all code to do frontends/lsiteners before backends, would probably be a fairly simple way of starting to improve/avoid this for mopidy's case. |
For the records: after some discussion on IRC, we've landed at a simple solution that will make
In non-simple cases, the application developer will have to shut down actors in the correct order himself. This should be documented. |
On line https://github.com/jodal/pykka/blob/master/pykka/actor.py#L164 the check for the run-able state is done before
inbox.get()
which can block for any amount of time, during this waiting run-able can very well have changed.Symptom of this problem is not finding the refs that you expect in the actor registry. This happens easily when stress-testing with a lot of clients in my current mopidy branch. For each new connection a ThreadingActor is started and as socket data is received it is delivered as a message. Then I
CTRL^C
mopidy and it stops all the actors, however, since some of my actors have messages in their inbox still they will go on to handle them despite being stopped. Part of this handling includes looking for other non-running actors which of course fails.The text was updated successfully, but these errors were encountered: