kquick
commented
3 years ago I don't mind multiple questions, although it might get somewhat confusing to have multiple threads of responses, so let us both feel free to split a question into a separate issue if things get confusing here.
1: Keeping an actor alive
There are a couple of ways you could do this: A. Create an actor P on startup whose only responsibility is to startup actor A. Actor A is no longer a top-level actor and has parent P, so P will be able to restart A if A exits. Clearly, this moves the concern to actor P, but if actor P does nothing else, then it's not likely to exit until the ActorSystem shuts down. B. Use the Thespian Director (https://thespianpy.com/doc/director.html)to manage the startup and functioning of your Actor System. This also requires shifting to use loadable actor implementations, but there are some significant other advantages that can be gained by that shift as well. In this mode, the Thespian Director provides the functionality of actor P described above, with the ability to perform additional message sending on startup, shutdown, and restart to help initialize or re-initialize your configuration.
2: No ask for the Actor class
The reason there is no ask is that ask is a blocking operation. At the fundamental level, an actor should:
- receive a message
- internally process the message
- send one or more messages
- exit the receive code (preparing it to return to #1). While it is performing steps 1-3, no other messages are delivered to the actor; this is what keeps actor code simple and avoids the need for mutexes or other parallelization synchronization techniques.
If the message received in step 1 cannot be handled in that single invocation, but must get a response from another actor to continue the processing, it should arrange to resume processing of the request when that response is received, but it should not block waiting for that response because it prevents it from handling other messages. To do this, you can either (a) store the original message internally to the actor, where it can be retrieved and processing can continue when the other actor's response is received, or (b) attach the original message to the request to the other actor and ensure that the other actor returns that original message as an attachment to the response. In general, (b) is the preferred mechanism to use, because it keeps the state management in the messages and not in the actors themselves; this is important because if an actor dies and is restarted, it can simply resume processing messages and doesn't require a re-initialization. Method (b) is also preferred because if the second actor never responds for some reason, the original request is not still consuming resources in the first actor (although an alternative is to use a self.wakeupAfter to send a failure on old messages that have not been responded to).
In short, the "await" technique is a mechanism used for process-based or thread-based synchronization techniques, whereas an actor-based approach does not use those types of mechanisms and is fundamentally oriented towards receive-respond message handling technique, so you will need to deal with "message/response hell", but you will never need to deal with synchronization and deadlocks.
htarnacki
hi, i hope you do not mind this type of task, collecting all my questions in one thread
Looking into documentation i see that named actors do not have parents and therefore there is no any actor that could receive "ChildActorExited" message. But i guess that an actor system itself is receiving such a notification? So i am looking for something like this: ActorSystem().createActor(actor_class, globalName=attr, keep_alive=True)
Without something like "await" are we going to some kind of callback hell? (or a message/response hell? ;-)) or is there something like: self.await( BankAccountData, self.send(BankActorAddress, AskForBankAccountData(client_number) )
self.await would stop an actor processing until there is a message of type BankAccountData that an actor receive from BankActorAddress