Actor Troupe, async asks and exception handling. #2

Closed
parkx408 opened this Issue Jan 20, 2016 · 6 comments

Comments

Projects
None yet
3 participants
@parkx408

First of all, thanks for sharing the awesome package.
I have been using it to prototype a data pipeline control layer.
I have some experience with Akka which is biasing my expectations but here are some requests/questions.
Note that I am completely new to Python and some questions probably will sound silly.

Three things threw me off a little although I am getting used to them.

One is the blocking nature of ask.
What would be the best way to ask asynchronously?
Do you have some recommended pattern? Is there a plan to support this out of the box?

Second is Actor Troupe.
This would be really useful feature but the documentation on this is seriously lacking.
Could you provide some examples on how to set this up?

Third is Exception handling.
If I wanted to ensure that all exceptions thrown by the child actor can be caught in the parent actor, would I have to simply catch all and send it to the parent? Or should I just not do that?

Thank you.

@kwquick

This comment has been minimized.

Show comment
Hide comment
@kwquick

kwquick Jan 20, 2016

Contributor

Thank you for the supportive feedback; it is always nice to know when people find Thespian to be useful.

To answer your specific questions:

  • The ask() method is used from non-actor code to talk to actors. Actors themselves should always use send() to talk to other actors (and to the non-actor code that originated the ask(). Most use cases find ask() to be a convenient methodology because that code is usually written as synchronous code: the "outside-world" code submits a message to the actors and waits for a response. If your external code also wishes to operate asynchronously to the actors, you can use tell() to send a message in to an actor (http://thespianpy.com/using.html#sec-6-5), and later you can use listen() to wait for a message sent back by an actor (ask() == tell() + listen()).
  • The documentation on Actor Troupes is lacking because... well... because the implementation is lacking. :-) This should have been noted in the documentation, but Troupes are still conceptual and not yet implemented. They are planned for sometime in the next six months, although hearing that there is demand for them will help to prioritize the effort.
  • If an actor throws an exception, Thespian interprets that as a failure by the actor. Thespian will automatically re-attempt delivery of the message in case the exception was due to a transient issue; if it is handled successfully the second time, then all is well and no other action is taken. If an exception is thrown a second time, then Thespian will wrap the message in a PoisonMessage wrapper and send that back to the parent actor (the one that created the actor experiencing the exception, see http://thespianpy.com/using.html#sec-4-4). The parent actor is free to ignore this, or to take some specific action to handle it. Thus, the short answer to your question is: you don't need to do anything: parents will automatically get a PoisonMessage indication if the child throws an exception.

Thanks again for the feedback, and feel free to follow up on any other questions or concerns; there is also a mailing list (info at http://thespianpy.com/#outline-container-sec-5) for discussions.

Contributor

kwquick commented Jan 20, 2016

Thank you for the supportive feedback; it is always nice to know when people find Thespian to be useful.

To answer your specific questions:

  • The ask() method is used from non-actor code to talk to actors. Actors themselves should always use send() to talk to other actors (and to the non-actor code that originated the ask(). Most use cases find ask() to be a convenient methodology because that code is usually written as synchronous code: the "outside-world" code submits a message to the actors and waits for a response. If your external code also wishes to operate asynchronously to the actors, you can use tell() to send a message in to an actor (http://thespianpy.com/using.html#sec-6-5), and later you can use listen() to wait for a message sent back by an actor (ask() == tell() + listen()).
  • The documentation on Actor Troupes is lacking because... well... because the implementation is lacking. :-) This should have been noted in the documentation, but Troupes are still conceptual and not yet implemented. They are planned for sometime in the next six months, although hearing that there is demand for them will help to prioritize the effort.
  • If an actor throws an exception, Thespian interprets that as a failure by the actor. Thespian will automatically re-attempt delivery of the message in case the exception was due to a transient issue; if it is handled successfully the second time, then all is well and no other action is taken. If an exception is thrown a second time, then Thespian will wrap the message in a PoisonMessage wrapper and send that back to the parent actor (the one that created the actor experiencing the exception, see http://thespianpy.com/using.html#sec-4-4). The parent actor is free to ignore this, or to take some specific action to handle it. Thus, the short answer to your question is: you don't need to do anything: parents will automatically get a PoisonMessage indication if the child throws an exception.

Thanks again for the feedback, and feel free to follow up on any other questions or concerns; there is also a mailing list (info at http://thespianpy.com/#outline-container-sec-5) for discussions.

@parkx408

This comment has been minimized.

Show comment
Hide comment
@parkx408

parkx408 Jan 20, 2016

Thank you for the quick turn around and detailed explanations.

I think I understand although I will have to try things out more to get a full grasp on tell() + listen(). The use case we have is where the we have limited number of threads that serves user requests. If we have one thread waiting for each of the job served by the actors, we might run out of threads pretty quickly and start to block user requests.

I will be waiting for Actor Troupe. :) Currently I am creating a list of actors and sending messages to each in a round robin manner. (Where each actor is essentially copying a portion of a table)

Thanks for the pointer on PoisonMessage - this makes a lot of sense.

Thank you for the quick turn around and detailed explanations.

I think I understand although I will have to try things out more to get a full grasp on tell() + listen(). The use case we have is where the we have limited number of threads that serves user requests. If we have one thread waiting for each of the job served by the actors, we might run out of threads pretty quickly and start to block user requests.

I will be waiting for Actor Troupe. :) Currently I am creating a list of actors and sending messages to each in a round robin manner. (Where each actor is essentially copying a portion of a table)

Thanks for the pointer on PoisonMessage - this makes a lot of sense.

@kevincolyar

This comment has been minimized.

Show comment
Hide comment
@kevincolyar

kevincolyar Sep 19, 2016

Are Actor Troupes still a work in progress? I don't see any references to them other that in the docs and a code comment?

Are Actor Troupes still a work in progress? I don't see any references to them other that in the docs and a code comment?

@kwquick

This comment has been minimized.

Show comment
Hide comment
@kwquick

kwquick Sep 20, 2016

Contributor

My apologies for the delay on handling this issue, but at this point I have uploaded a provisional implementation of the troupe functionality, with an example showing how it is used (https://github.com/godaddy/Thespian/tree/master/examples/fibtroupe).

This is provisional at this time because I would like to get feedback on the usefulness and possible changes needed before formally adding this to the supported Thespian implementation (with associated documentation). There were many possible approaches, but the current implementation (which is similar to the approach that parkx408 describes) seems to be a good balance of simplicity, functionality, flow-management, and ease-of-use. Please try it out and post any feedback you have.

Contributor

kwquick commented Sep 20, 2016

My apologies for the delay on handling this issue, but at this point I have uploaded a provisional implementation of the troupe functionality, with an example showing how it is used (https://github.com/godaddy/Thespian/tree/master/examples/fibtroupe).

This is provisional at this time because I would like to get feedback on the usefulness and possible changes needed before formally adding this to the supported Thespian implementation (with associated documentation). There were many possible approaches, but the current implementation (which is similar to the approach that parkx408 describes) seems to be a good balance of simplicity, functionality, flow-management, and ease-of-use. Please try it out and post any feedback you have.

@kevincolyar

This comment has been minimized.

Show comment
Hide comment
@kevincolyar

kevincolyar Sep 21, 2016

Awesome, thanks! I'll be trying it out today.

Awesome, thanks! I'll be trying it out today.

@kwquick

This comment has been minimized.

Show comment
Hide comment
@kwquick

kwquick Nov 8, 2016

Contributor

Actor Troupe support is now officially part of the 3.4.0 release (https://github.com/godaddy/Thespian/releases/tag/thespian-3.4.0).

Contributor

kwquick commented Nov 8, 2016

Actor Troupe support is now officially part of the 3.4.0 release (https://github.com/godaddy/Thespian/releases/tag/thespian-3.4.0).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment