In one of my Akka applications (my first, and not one I'd hold up as a shining example of how to write such systems), I implement a low-water / high-water work generation strategy driven by a heartbeat. The low and high water marks are defined in terms of number of work actors active, each of which does one thing and is created by a manager. That manager keeps track of started and as-yet unompleted workers and can respond to requests from the work generator for the current activity count. The response to these inquiries provides the information as to whether work in progress has fallen below the low-water mark and new work should be generated.

It's kind of crude and in a new system I'm working on now the connections between work generation and work execution, as well as checkpoint logging, is done in a more continuous, less "batch-oriented" manner. This system is about to be deployed, so at the moment I can't say for certain how it will perform, but I'm pretty sure it will exhibit better behavior than the earlier system. It's also inherently more complicated that the earlier system in how it generates, performs and records the work it does.


[Going to put this also as a valid answer]

If the actor who needs the count is not the parent and/or cannot retrieve the ActorRefs of the target actors, then the following might be an alternative.

Counting the number of actors of a certain type can be done by sending a "head count" message, holding an ActorRef array, passing each actor. Then each target actor can add it's ActorRef to that list and forward the message. But this depends on the nature of the system and works only if you know beyond any doubt that you don't have any actors spawning up during the "head count".

Related Query

More Query from same tag