Reassigning actors?

[Daklu]

I think the hierarchical nature of actor communication at run time is a great starting point for organizing an application.  It especially helps do a controlled application shutdown.  One thing I've kept in the back of my head as a potentially useful feature as I've learned actor-oriented programming is the ability to change an actor's calling actor.  I mentioned it to Allen yesterday but he didn't think it was possible with the AF.  Can AF be extended in a way that this would be possible?  (Unfortunately my LV2012 download got corrupted and it will be a bit before I can try again.   )

I don't have any specific need for the capability right now and I'm not sure I ever will.  It certainly adds a layer of complexity to an actor oriented design.  Still, as far as I can tell the actor communication hierarchy is fixed at edit time and can't be changed at run time.  The idea of sending actors as messages between application components and/or dynamically building actor hierarchies strikes me as an interesting area to explore.

[David_Staab]

Seems like this can be most easily achieved by defining a Message Dispatcher. Every Actor  sends their Enqueuer to it along with the GUID of their Caller.

[AristosQueue (NI)]

The hierarchy is not fixed at compile time. It can be set at runtime. However, it cannot be changed while the actor is running. That's a deliberate design. If you want to change the caller of an actor, stop that actor, catch the Last Ack message and get the actor's final state from that message and then pass the actor to the new caller to relaunch it.

The "I am your interface to the world" nature of the caller to actor relationship is so foundational to the setup of the framework and its guarantees, and without some use cases, I'd be loathe to tamper with that.

[EDIT: I added another post below that is a second implementation for this, in case anyone in the future comes looking for a solution to this problem.]

[Daklu]

If you want to change the caller of an actor, stop that actor, catch the Last Ack message and get the actor's final state from that message and then pass the actor to the new caller to relaunch it.

Doh!  Now that you mention it I remember that's what Allen told me too.  Not ideal but probably a viable workaround.

The "I am your interface to the world" nature of the caller to actor relationship is so foundational to the setup of the framework and its guarantees, and without some use cases, I'd be loathe to tamper with that.

Perfectly understandable.  I wouldn't expect you to change the framework without solid use cases that are difficult to address with the current design.  Seeing as how I don't even have any imaginary use cases... *shrug*   Mostly I'm just publicly wondering if there's any value in the idea of changing ownership.

[AristosQueue (NI)]

Daklu wrote:

Perfectly understandable.  I wouldn't expect you to change the framework without solid use cases that are difficult to address with the current design.  Seeing as how I don't even have any imaginary use cases... *shrug*   Mostly I'm just publicly wondering if there's any value in the idea of changing ownership.

There is another way to implement "change of owner"... that is that you have the nested actor send messages to a queue that it has in its private data. It initializes that queue to be the original caller queue. A message sent to the nested actor could replace that local queue with the new queue. The built-in message of Last Ack would still go to the original caller, but the nested actor could be written itself to send all messages to that private data queue.  Since the original caller can be designed to quit without stopping the nested actor, you now essentially have a reassignable actor without having to stop and restart it. The only cost is you have to implement your own "send last ack when I stop" system.

[drjdpowell]

I think another option is to make all your output messages "Self-Addressed", and use the "Zero-coupled" method of having the caller provide child messages (which would be pre-loaded with the address of who to send the message to).  Then provide a message that replaces these self-addressed messages with new ones that point to a different actor.  That would redirect the message flow (except for Last Ack and all that).  You might need to update the child output messages anyway to ones appropriate to the new "caller".  This method might be more flexible, in that one could redirect only some of the messages, and one could define a child mesage that sends messages to more than one other actor (whether AQ would think that extra flexibility is a good thing is another issue ).

-- James

[AristosQueue (NI)]

drjdpowell: It's the equivalent of just handing the child another queue to short circuit the tree for certain messages. The owner remains the same for the messages that are built into the framework. Passing it a short circuit queue is generally easier than wrapping all the messages.

[drjdpowell]

AristosQueue wrote:

drjdpowell: It's the equivalent of just handing the child another queue to short circuit the tree for certain messages. The owner remains the same for the messages that are built into the framework. Passing it a short circuit queue is generally easier than wrapping all the messages.

I'm imagining a highly reusable actor, where one already is providing child-classes of the output messages for "zero-coupling"; the extra work of including the address in the messages wouldn't be much more I would guess (True? False?).  And the result would an actor whose caller has full individual control over where its messages are directed.  But you're right, sending all messages to a single queue would be easier.

[drjdpowell]

...easier than wrapping...

Oh, BTW, I'm not referring to the current "Self-Addressed" message implementation, which seems (in the 2011 version at least) to wrap another message.  I would build the address in to a parent of the actor's output messages.