what is the recommended approach to mocking child actors, say, I have actor X which internally creates A and B. I'd like to test only X and would like to substitute A and B with test probes and probably autopilot(?). However, because X does
Context.ActorOf it doesn't seem possible, unless, of course, there's way to hook into some Context.ActorOf test callback if one exists. Another approach I've found is to pass a dependency into X which is responsible for creating children and substitute it when testing. Or... maybe just extend the static Props actor creator for X and make it receive a lambda which takes in the Context
How can I best load test my actors?
I'm considering rewriting my unit tests for an FSM because they often unnecessarily break when changing implementation details of the FSM. https://www.planetgeek.ch/2011/05/17/how-to-unit-test-finite-state-machines/ advises against calling a method like
SetState in the unit test, and advises testing for side-effects external from the FSM. That certainly sounds like it could reduce test breakage. Anyone here experienced with testing FSMs? What do you recommend?
@snekbaev actors can promote a bit different approach to unit testing. Since a single application feature can be result of work of multiple actors, testing them in isolation sometimes just doesn't make sense. Actors work together in systems, and sometimes it's best to test them as such.
@stijnherreman from my experience in any message based system the best way of working is to have a collection of inputs that you wan to test (they also are responsible for moving state machine to a desired state) and then just assert outputs and side effect. In practice internal state and implementation doesn't really matter as long as FSM reacts with world around it as designed.
@Horusiath I've test covered the child actors individually (they don't have their own children), but I'd like to test the orchestration logic for their parent, for example, that it stashes correctly, takes certain actions depending on what children reply. Of course I could leave as is, but in this case will have to mock a lot of things and I don't really feel like I need to do that in this specific case. What I'm trying to do now: I created a nested class for the parent which inherits in interface for creation of Props for A and B. Then I added one more static Props methods in to X for its own creation, one overload takes IChildCreator. Now I'm trying to mock this interface and return a test probe with autopilot and see it this even works :)
heh, it seems to work, but will test further. If somebody needs to pass a probe and return Props - a dummy wrapper seems to do the trick (found online):
public sealed class TestProbeWrapper : UntypedActor
{
private readonly IActorRef _target;
public TestProbeWrapper(IActorRef target)
{
_target = target ?? throw new ArgumentNullException( nameof( target ) );
}
protected override void OnReceive( object message )
{
_target.Forward( message );
}
}Props.Create( () => new TestProbeWrapper( getActorProbe ) )
@Horusiath what is a more typed way to make an Ask?
let loop (ctx: Actor<Msg>) (state: State) = function
| GetConfiguration ->
ctx.Sender() <! (Ok state.Configuration : Result<Configuration, string>)
ignored()here if I remove the type hint it's inferred as Result<Configuration, obj> which results with disasters.
It's an entry point to the actor system, so I cannot pass an IActorRef<>.
@vasily-kirichenko popular option is to use replyTo pattern (add a field to a message, usually called
ReplyTo), which contains an actor to which you may want respond to. Then in code instead of sending reply to Sender, send it to msg.ReplyTo. This could work with ask via Ask overload - tbh. I'm not sure if this method is already published.
@jaydeboer read this: https://getakka.net/articles/actors/receive-actor-api.html#initialization-via-prestart
When actor A sends a message to actor B, and B is supposed to reply to A with some data, how do I inform A of a failure in one of B's children? This cannot be done with a supervisor strategy it seems? The goal is to let A know it should stop its process and shut down, logging a failure somewhere.
I wonder what would be the best way to investigate timeout problems with SqlServer adapter. Recovery of persistent actors in our system sometimes fail with timeout exception. When we traced low-level db activities we found that sometimes INSERT into EventJournal doesn't return for a long time (example: 42 seconds), and it blocks SELECT from the same PersistentId. Such long time on INSERT doesn't make sense, but we are using BatchingJournal. Can this be part of the problem? /cc @Horusiath
It's all Akka EventJournal adapter
this one? :)
there are also max-batch-size, max-buffer-size and max-concurrent-operations
it works like that: batching journal buffers incoming write requests (the max size of that buffer is
max-buffer-size=500000, after that size is reached any more writes will be denied until buffer will be freed). These writes are picked into batches (up to max-batch-size=100) and every batch is essentially a single db request - keep in mind that if you store mutliple events in a single Persist request, they all count as 1 atomic write.
last, since db requests are asynchronous by default, we don't call them one by one. Instead we execute many of them up to a given concurrency limit (
max-concurrent-operations=64). keep in mind, that every operation uses separate db connection - ADO.NET is pooling them and afaik pool size is 100 by default.
also max concurrency limit is specific to batching journal, not shared with snapshot store, but they still use the same ADO.NET pool given the same connection string. So they can compete for connections in the pool. If you want a separate pool for snapshot store you can specify a different connection string for it - if I remember correctly ADO.NET allocates connection pools based on connection string matching
@vasily-kirichenko I wanted to, just haven't got time to implement it. Current implementation was more inline with the one, that already existed before, so I wanted to be sure that it could work as drop-in replacement without breaking things. Tbh, if akka.persistence was implemented on top of streams, batching journal and normal one would probably differ only with the stage in between performing the batch operation.
Hi All...I have implemented Akka.NET in a dispatcher / worker pattern to distribute load across multiple machines for a job processing system. On the remote machines I have a service running with Akka workers waiting to accept remote requests. When the worker (actor) is created, it instantiates a type using Assembly.LoadFrom - the location to load the dll is passed as part of the worker creation request. Then, requests to process an xml data file are sent to the worker actors which should use the assembly that was instantiated when the worker was created to process the data. My main dispatcher works with batches of data (a job) and in between jobs, stops the remote workers. When a new job is created, it creates new workers to process the job. This is working fine however on subsequent jobs, where the source .dll has changed, it seems that the old .dll is being used instead of the new one. On each new job, the dispatcher first pulls the assets (dll and other files) to a new file share where the worker should load it from and I can see from my logs that the new worker is using the correct location however the results are showing its using the .dll from a previous job (worker). I am creating my actors with a unique name and I thought this would give some isolation as new, unique workers would be created. What am I missing that the remote process is re-using workers or the .dll. I know something is not quite right as the remote service has a lock on the .dll even after its finished and the workers have been stopped as when I come to delete the assets in the shared folder, I'm unable to until I shut down the remote service. Sorry for the long winded description - Any ideas?
Hi Stijn....Thanks for the quick response....I thought (clearly incorrectly) that multiple actors would have separate AppDomains but I guess this is not the case. Is there anyway in the Akka config to have workers created in separate AppDomains so I can 'config' out this issue or do I need to write this into my worker?
@stijnherreman - Thanks. I guess it wouldn't be too hard to create an AppDomain to execute on. Is this just a general issue / thing to bear in mind with Akka that if you change any of the binaries for execution, you would have to restart the remote host process every time? Does anyone know of a way to do this from Akka config? Is this something to do with the Akka dispatcher?
@mikeprag It doesn't sound like running actors in separate AppDomains fit well actors nature. Actors have very small footprint (few hundred bytes), they don't have allocated threads, they just borrow threads to process messages. AFAIK an AppDomain drags a memory footprint of at megabytes, not even kilobytes (didn't find any figures but will be very surprised if it's below 1 meg). This shouldn't stop you from creating additional domains, but I think you need to do it outside actor system.
what's the right pattern for implementing throttling functionality with actors? I would like to have an actor receive a message with a collection of things to process, and it would create a new actor to process each one, and it should be able to limit the number of outstanding operations (child actors who have not replied yet)
if I understand correctly the one message at a time promise, once this actor receives the message with the collection of items to process and starts creating child actors, how will it know that one of these child actors has replied, if it can't process that reply message until it's finished processing the one with the collection of items?