Does this exist already? I would like to create a new type of actor that will have its own on-going (parallel execution) process. I wanted to put a java.lang.Runnable reference inside the actor and dispatch a thread to run with it. The priority of this thread must be balanced against other Akka threads. It gets a little complicated that way. Is there a framework for doing this? Has it been done before?
From the get-go this sounds like a suspiciously bad idea.
But I might be missing something, and the description of what you’re trying to achieve is rather confused for me, so I don’t get it.
In particular, can you explain what you’re trying to achieve, why and a simple example of when to use your idea?
I would like to have a Akka actor be a sort of controller to some other on-going continuous process. I explained one approach of doing this by putting a java.lang.Runnable in the actor itself. This approach is direct and I agree risky and probably bad idea. I am fishing around to see if this was ever done before.
Note: There are other much more safer ways of doing this. One better and safer way is to have the actor have a reference (maybe some IP address or DNS name) to a container (like Docker) instance running the on-going and continuous process on a different machine, maybe a different host altogether. This way the AKKA actor can communicate with the Docker container and control it. This can be repeated a big number of times.
This started to make me think that AKKA could use an extension that would allow it to control either Kubernetes or Docker or some other container technology so that an AKKA actor can have a reference to a Kubernetes Pod (a Pod can have one or several container) running on a different host. There are many applications where this can be useful. I might be interested to create such extension for AKKA.
I write robotics applications where I need a number of parallel processes (from 4 to 200) being intelligently controlled by a controller and these controllers should be able to communicate. The actor model is ideal for implementing the controller, but for implementing the parallel on-going processes, the Docker container is also ideal. These to systems (AKKA and Kubernetes/Docker) should have a framework to work together.
Ok, now I’m starting to have a clearer picture.
My view of having a different Runnable reference kept inside the actor would be suboptimal and error-prone:
- each
Threadis a precious and costly resource, that’s why akka makes extensive reuse of those if possible, using a sort of time-sharing. You want to start an external process from within the actor, but all you need to keep inside of it is the needed logic to start that process, you can simply create aFuturethat will execute the logic, possibly on a dedicatedThreadPoolthat’s shared between all the “controller actors”. This way a thread is used only as much as needed in the simplest possible way. - You need to additionally consider what kind of resources the controlling procedure will need, any IO intensive operation (most probably like connecting to an external socket and control Docker containers or K8s pods) should be kept under control in a separate pool from those running your actors (you can find lots of advice on this on the akka docs too).
- You should also find some way of possibly get some feedback from the process in an async way, which would not be too easy, but maybe you can figure some way
Please add some details if you want
For inspiration, there is something like this in https://github.com/typesafehub/akka-contrib-extra/tree/master/src/main/scala/akka/contrib/process
We don’t actively maintain that code so you should reuse by copy if it is something that matches your problem.
Why don’t you use Futures? As long as you understand the limitations (basically don’t directly call methods on Actors from a future, send a message) they work fine with Actors, and you can run them against a specific thread pool if you need to, so you have the sort of control you describe.
This started to make me think that AKKA could use an extension that would allow it to control either Kubernetes or Docker or some other container technology so that an AKKA actor can have a reference to a Kubernetes Pod (a Pod can have one or several container) running on a different host. There are many applications where this can be useful. I might be interested to create such extension for AKKA.
I’ve done exactly that using Skuber (GitHub - doriordan/skuber: A Scala Kubernetes client library) to write an Akka-based controller running in a K8s pod that starts up other K8s worker pods on demand. I’m not convinced it’s worth writing an extension to Akka for it though, the Skuber API is “fluent” so it’s easy as it is to create new Pods on the fly. The only additional thing I did was to abstract the various Pod settings into a higher level config file and I used Typesafe HOCON to do that. All the bits you need are there already, it’s just a question of plugging them together.