How do you Identify Actors?

[drjdpowell]

rik_aspinall wrote:

it seems to me that passing the actual actor queue might be undesirable, since A can pass to B can pass to C, which means A and C are now directly talking, which I may not want

If one is doing zero-coupled messages (i.e. a calling actor is providing the message that the callee will fill and send back to the caller) then there isn't any issue, since the caller obviously knows the callee's enqueuer.

[CaseyLamers1]

I will add to my previous statement about the tree hierarchy. I only use zero coupled messages to talk up the tree. I recommend figuring out this method and sticking to it. Any given actor only has queues for the things it launched as a nested actor and the queue of its caller.

[rik_aspinall]

Thanks Casey. A few questions:

Is it ever possible that a "bad" component would send a stop message to your error actor? How do you avoid this?

I assume then that if some terrible error is noted, your error actor would send a message to the root actor and let the correct shut down sequence trickle down. Would it be possible to send a bad message unsolicited to induce shut down in such a way? How would you avoid this?

I of course am less cynical than this in many of my endevours, although substitute "bad malicious programmer hacking into critical infrastructure" for "lazy developer who knows too much about the system" and "myself" and you may find yourself answering the same questions!

[CaseyLamers1]

The error logger doesn't do anything with sequencing handling response to errors. Handling errors goes up the chain as far as I decide is required based on the scope of information needed to make a decision. Sometimes the error is handled on the spot, sometimes it goes up one level, sometimes it goes up to the top.

When I write the code I create a Q constant in the private data for the error logger. I only send "Log Error" messages to the error logger. The top level system decides when to stop the error logger.

[drjdpowell]

rik_aspinall wrote:

Is it ever possible that a "bad" component would send a stop message to your error actor? How do you avoid this?

Note that one can wrap enqueuers inside other objects that provide limited access, so an object that allows one to log an error, but not send a stop message.

rik_aspinall wrote:

I assume then that if some terrible error is noted, your error actor would send a message to the root actor and let the correct shut down sequence trickle down.

I would assume that Casey's "error logger" is just logging errors for future diagnosis.  Because logging doesn't feed back into the application, it's OK for it to be an exception to the usual rules.

[rik_aspinall]

Would you be able to describe this technique a bit more?

Note that one can wrap enqueuers inside other objects that provide limited access, so an object that allows one to log an error, but not send a stop message.

Right now, I can imagine having a VI perhaps that people use (a send message VI without the enqueuer as an input, perhaps that is friends with something that will provide e.g. the error logger's queue at runtime) but if I follow AQ's earlier suggestion of using the enqueuer to identify the actor, then I could just send the bog standard actor stop also. But anyways, please elaborate as this sounds promising.

Thanks,

Rik

[drjdpowell]

rik_aspinall wrote:

Would you be able to describe this technique a bit more?

You can create a "Error_Logger_API" class, with a creation method that takes an Enqueuer to the Logger Actor, and a "Log" method that takes an error and sends it to the Logger Actor.   The Top Level Actor launches the Logger Actor and creates an Error_Logger_API object with the Enqueuer.  Then it can pass that object around to other Actors, giving them the ability to log errors, without the ability to send any other message to the Logger Actor.  

You can let the Top Level Actor provide any identifying information you like in the creation method of the Error_Logger_API, and have this info be attached to the logging messages.

I do a lot of stuff similar to this with my actor-oriented (but not AF) framework.  There is lots of cross-tree comunication, but it is mostly via wrapper objects that limit what can be sent.   For example, the top-level actor may pass actorA the ability to sent "DataX" messages to actorB, but actorA cannot send any other message to actorB.  Note that this means that all inter-subactor messages are specified in the Caller's code, even though such messages don't actually route through the Caller (as is standard in the AF).  Thus the Caller's "domain" is in full control.

[AristosQueue (NI)]

My presumption is that X only needs to be able to identify Y in cases where X is going to communicate with Y. There are not, to my knowledge, any use cases where X needs an identifier for Y where X isn't already in communication with Y.

If you're just doing error reporting or something like that, then there's no need for X to identify Y... you can turn the Enqueuer into a string and use the resultant string integer as an identifier embedded in an error report. No need for any receiver of that error cluster to ever interpret the ID as an enqueuer.

If you have a use case where X actually needs to be able to make decisions based on the ID of Y but does not already have communication with Y, please post them.

[AristosQueue (NI)]

Casey is (justifiably because of the scale of his system) paranoid. I would amend his statement slightly -- if you can learn to use the zero coupled method exclusively, then you can make informed decisions about when not to use it without that decision being driven by fear of the zero coupling system. The fear factor ("oh, I don't really know how to do that... maybe it will be too much performance hit... it complicates my architecture...") drives too much bad architecture. So get yourself to the point where you are able to use zero couping for every upward-going message. After that point, you can reasonably make a case-by-case call. There are many times where I will choose increased coupling. But bias toward zero for anything that is expected to scale over time!

[rik_aspinall]

I suppose the architecture I'm envisioning has the top actor that runs the program divided into different roles: error policy handling, event logging, configuration management and actor management. So I have four queues to these guys, rather than to the actual top program. Ultimately the actor manager should be responsible for creating the tree of lower actors. I'm trying to find a way of allowing the tree structure for important things (opening, closing, linking) actors but bypass it for the common operations such as communication. I would like the important operations to be highly controlled, but once something has been verified, to allow comms with much less baggage. Based on probability, the additional overhead for being cautious in the control tree forming messages should not be too frequently experienced. I would say that I think I understand zero-coupling, but for me its use would be more in the non-control tree scenario, as that would be where I would expect the variation to occur.

So I could use zero coupling in the control tree (I'm already using low coupling) but I don't see how that helps me. All these lower actors can declare a method that the higher level actor can define in the Do (*)

To me, what I don't want happening is the lower level actor sending the stop command to the higher actor. And hence a kind of filtration such that the tree is preserved for important messages, but not others. So drjdpowell seems to have something which could work.

There's a perfectly valid argument to be made about just using a separate queue for comms, although I like the way the AF has priority queueing and is fairly good at cleaning up after itself. Maybe I just need to go with that instead. I also find myself intrigued but not quite tempted by Dimitry's solutions (https://decibel.ni.com/content/docs/DOC-41864) and related (http://www.labviewcraftsmen.com/blog/fun-with-the-actor-framework-pubsub). I'm trying to get the best of both worlds I suppose.

* Can two different nested actors declare the same abstract method that the higher actor fulfills with just one "Do"- perhaps an abstract abstract method?