Skip to content
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

Waiting for actor to finish #51

Closed
kevincolyar opened this issue Dec 8, 2017 · 3 comments
Closed

Waiting for actor to finish #51

kevincolyar opened this issue Dec 8, 2017 · 3 comments

Comments

@kevincolyar
Copy link

I have a simple two actor setup:

  • CalulcationActor generates a large set of messages and sends them to its child actor, SaveActor.
  • SaveActor that saves the messages to the database

Once the CalculationActor is finished, I would like the system to shutdown.

However, the CalculationActor finishes well before the SaveActor has received and processed all of its messages. I've tried sending an ActorExitRequest once the CalculationActor is done, which also sends an ActorExitRequest to the SaveActor, but it appears that the exit message is received before the messages to save and exits before all messages have been saved.

Is the due my SaveActor being a ActorTypeDispatcher? Perhaps ActorExitRequest is not queued behind the other messages?

Is there a pattern for shutting down the system after all actors have finished processing?

@kquick
Copy link
Member

kquick commented Dec 12, 2017

Hi @kevincolyar,

There is no guarantee of message delivery order in Thespian. Most of the time they will be delivered in the order sent, but there are cases where message arrival doesn't match the send order.

There should be affect on the message ordering when using the ActorTypeDispatcher.

There are a couple of different approaches I would recommend for this situation:

  1. If the CalculationActor knows how many messages are going to be sent to the SaveActor, use a separate message to communicate this information to the SaveActor. The SaveActor can then know when all the work is completed and notify the CalculationActor, at which time the shutdown can be performed. This could also be combined with assigning each CalculationActor result an ID number that the SaveActor can use to confirm receipt and possibly order (if order is important).

  2. An easy alternative is to use a @transient_idle decorator with the SaveActor (http://thespianpy.com/doc/using.html#hH-99783a4a-183f-4b69-8910-014d01edbf1c). The shutdown will be delayed by the idle period, but if the Calculation Actor normally generates output in rapid succession, the delay could be fairly small. The CalculationActor can use the ChildActorExited that it will receive when the transient SaveActor exits to know when to exit itself.

  3. The SaveActor can send back a response for each message it has received. This doubles the number of messages exchanged between the actors, but if the SaveActor storage operation is the bottleneck this increased message count may not be a significant factor. This would allow the CalculationActor to know if and when each result has been saved (and ultimately, when to shutdown).

  4. You could potentially increase the performance of the SaveActor by batching saves to the database. For example, save CalculationActor results in a local Python array, use a self.wakeupAfter(timedelta(milliseconds=600)) and on receiveMsg_WakeupMessage(self, msg, sender) it could save the entire array. You would still need a completion indication as described above, but this could potentially help the SaveActor keep up with the output of the CalculationActor.

I'd be happy to describe any of the above in further detail if you'd like. Also, I apologize for not responding earlier: using the issue tracker at https://github.com/kquick/Thespian may be a little faster for responses.

@kevincolyar
Copy link
Author

Thanks for your detailed answers, Kevin. I was actually able to convert my SaveCalculation actor to a troupe which can now keep up with the CaclulcationActor. Works great!

Thanks again for Thespian!

@kquick
Copy link
Member

kquick commented Dec 14, 2017

That's great news, and you're welcome: I'm glad it's useful for you.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants