I am using Akka TestKit but I have an actor which creates a child actor and sends it a message. The trouble is when unit testing I only want to test the parent actor in isolation however when I run the test it also invokes the child actor. Is there a way to prevent this? Seems I can add the child actor as a dependency and I can substitute this with a BlackholeActor from a unit test
@OnamChilwan TestKit is more integration-like test type than unit-tests, usually actors perform some business action in cooperation, so to test it, you need to make sure, that whole topology of actors is working fine
Stick to basic unit testing and assert agianst behavior as opposed to asserting messages have been published etc as this will be covered from integration tests via Testkit
@Rovak don't get me wrong, I really don't want to offend anybody here, but don't all those issues point to some complexity problems on your company app side?
then simply retrieve actual config for current service from it
@Horusiath no offence taken, the app is indeed pretty complex, its an enterprise service bus. The app may load multiple projects and these projects should never be allowed to share instances like repositories, database connections, services etc. so each project has their own ninject container. Right now some services which do work in different threads have locks which i want to replace with actors and message passing
there are a LOT of services, and i can't rewrite everything at once. So i want to create a migration path which may not look pretty in the beginning, but i can then slowly refactor everything to akka actors
@Horusiath I am still at actor pattern, my current problem is that before i had the same state-model-type for the AR-state and for the read-model. Now i am changing that the AR is using his own State-type. The problem is that the Sender of the create-command shouled be informed with the newly created read-model. I have the idea, to pass a non-persitent event to the EventBus so that the ReadModelProjector can tell the Sender of the create command the entity
But it seams wrong
@Zetanova the view side of persistence plugin is lacking some features. That's why it was obsoleted on the jvm side in favor of persistence queries (which we will probably done too, once streams and persistence query will be ported). Btw. this idea with using third mediator seems neat to overcome current limitations.
@Horusiath readmodel generation is working good, the batching is easy and working well. The buffer of events will be flushed on MaxEventCount and Timeout in a single actor for each AR-type. The events are then grouped by Id and each group is processed by the normal Read-Modify-Update CRUD pattern.
triggered by a special event, I could send the readed read-model back to a requestor,
The other option would be the normal one that the client is generating the read-model internaly on client-side and sends only the create-command, without getting the model back.
but then there is a lag, where one client-component has the read-model and maybe an other need it to be created on the read-side (some query)
@OnamChilwan you could do so, ie. by passing children
Props through actor's constructor (this is done in few cases) or as part of some message to be send at some point in time. But if those are making a solution too complex, then it's a warning, that maybe a hierarchy of actors should be changed or maybe they are so tightly coupled, that they should be tested as one.
If you block a receive handler. Then it will 'block' a thread on the threadpool. (if it will actually block/lock the thread that was running at that time, depends on your code ofcourse, if your doing async await things, it might not)
but if your doing a query, and it deadlocks, wont your dbdriver throw an exception of some kind ?
either way, there is no magic code in the Akka.Net dispatchers that prevents these kind of problems. It needs to adhere to the normal set of rules regarding the TPL like anything else.
Akka.net makes concurrency easier to implement, and prevents alot of the pitfalls that come with the territory. But its not perfect ;) (nothing is)
This feels kinda ugly
while (Context.GetChildren().Any(x => x.GetType() == typeof (Account)))
Is there a good way to 'monitor' for a deadlock in cases like this? Perhaps configuring the dispatcher's deadlines
then I wouldn't have this complex graceful shutdown problem
i have to cut off incoming messages and lets everything passivate, it shouldn't be hard but it is tricky to keep it simple and foolproof