Leaderboard

(Replace the lowercase actor below with process or subsystem or service... it's more general than an Actor Framework Actor.) I had a brief offline conversation about this topic the other day about the semantic difference between a command and a request sent to an actor. An actor receiving requests is generally in charge of its health and destiny; an actor sent commands is subject to DoS attacks or other hazards from external sources, whether incidental or malicious. As Dak mentions, separating incoming messages from the job queue is a great implementation for receiving requests (I owe a lot of my understanding and respect for this concept to the JKI State Machine). The visual below represents an actor (the traffic intersection) and its response to individual messages from four distinct non-owning-but-using actors (the incoming lanes) defining their own concepts of priority (drivers with their own agenda). Were this intersection handling incoming requests rather than commands, it performs its job more effectively (by coordinating order, rate, and even batch-ness by aggregating requests to provide efficiency) and reduces undesirable interaction between the four independent actors. (Finally, I don't assert requests sent to actors are universally better than commands, since they each have merits in different problem domains; just acknowledging the existence of this concept, especially when chain-of-command and ownership does not naturally exist.) Originally from: http://chivethethrottle.files.wordpress.com/2013/01/random-t-01_18_13-920-55.jpg

(I'm sure you--MJE--know most of the stuff I say below, but I'm spelling it out for the benefit of other readers.) I propose implementing an actor with the expectation that its message queue is a de facto job queue violates the one of the fundamental principles of sound actor design. Message queues transports and job queues have different requirements because messages and jobs serve different purposes. Message are used to transfer important information between actors. Actors should always strive to read messages as quickly as possible since any unread messages may contain information the actor needs to know to make correct decisions. ("ReactorCoreOverheated") Whether or not they immediately act on the message is up to the actor, but at least it is aware of all the information available to it so it can make an informed decision about what action to take. Jobs aren't serviced the same way messages are. Jobs are a mechanism to keep worker loops busy. They're more of a "Hey, when you finish what you're doing can you to start on this" kind of thing rather than an "Here's some important information you should know about" kind of thing. Commingling these purposes into a single entity is part of the QSM mindset I mentioned earlier and leads to additional complications, like priority queues. So how do you implement a job processor if it isn't an actor? Make it an internal component of an actor. Create a helper loop that does nothing but dequeue and process jobs. When the actor receives an AddJobToJobQueue message in its message handling loop, it places the job on the job queue for eventual processing by the helper loop. Sound suspiciously like an actor? It's not. The job processor is directly controlled by the message handling loop. Actors are never directly controlled by other components; they control themselves. The job queue can be manipulated by the message handling loop as required, even to the point of killing the queue to trigger the job processing loop to exit. An actor's message queue is never manipulated or killed by anyone other than the actor itself. There's a lot of gray between an actor and a helper loop. The implementations can look very similar. I try to keep my helper loops very simple to avoid race conditions often found in QSMs. They are very limited in what operations they perform. They don't accept any messages and send a bare minimum of messages to the caller. ("Exited" and "Here'sYourData.")

What use cases are you trying to solve? I want paragraphs describing particular functionality that you cannot achieve with the AF as it stands before we introduce new options. I created the AF in response to one repeated observation: many users need to write systems for parallel actor-like systems, but it takes lots of time to design one that is actually stable, and it is incredibly easy to destabilize them with the addition of features. I've built a few of these systems both with the AF and with other communications systems, and they are *hard* to debug, simply because of the nature of the problem. The more options that exist, the more you have to check all the plumbing when considering what could be wrong. We need the plumbing to be invisible! I stuck "learnability" as one of the AF's top priorities. I get mocked for that claim sometimes ("You call this learnable?!") but when compared to the nature of the problem, yes, it is a very approachable solution. Introducing options is a bad thing unless we are solving a real need. So don't tell me "I can't do filtering on the queue," because that's a solution. Instead, tell me "I can't process messages fast enough" or "I need to only handle one copy of a given message every N seconds". And then we can talk through how best to implement it. In the case of filtering, there's a fairly long thread on the AF forums about various ways to do this with the current AF, and general agreement that those are *good* ways, not hacks or workarounds to compensate for a hole in the AF. But are they limited in the types of applications they are able to write? That's the real question. Yes, the AF demands a particular programming style. That consistency is part of what makes an AF app learnable -- all the parts work the same way. If there is something that cannot be written at all with the AF, that's when we talk about introducing a new option. So, please, spell out for me the functionality you're trying to achieve. In terms of filtration, I think that's been amply (and successfully) answered. In terms of proxying, take a look at version 4.3. If there's something else, let me know.