These are chat archives for akkadotnet/akka.net

10th
Dec 2018
Chris G. Stevens
@cgstevens
Dec 10 2018 02:24

I am trying to test an actor that is using PubSub; _mediator = DistributedPubSub.Get(Context.System).Mediator.
But when I run my test I get a "System.NullReferenceException: 'Object reference not set to an instance of an object.'"
The DistributedPubSub doesn't seem to get initialized and not sure how or what I need to to do.
The website, https://getakka.net/articles/actors/testing-actor-systems.html#configuration, has a todo on it: TODO describe how to pass custom config as I figure I need the config.

Within the [Setup] of the test I tried adding the following with no luck.
Sys.Settings.Config.WithFallback(Akka.Cluster.Tools.PublishSubscribe.DistributedPubSub.DefaultConfig());

I doesn't even want to test the actual PubSub part... Are there any examples on this?

Havret
@Havret
Dec 10 2018 07:45
@cgstevens You can inject Mediator inside you actor and test it like any other IActorRef dependancy.
Peter Huang
@angrybug
Dec 10 2018 21:28
@cgstevens the problem might be that the test actor system is already initialised for you by testkit. You might want to create your own actorsystem setup with PubSub and that for testing. (Furthermore, you'll find Sys.Settings.Config.WithFallback(Akka.Cluster.Tools.PublishSubscribe.DistributedPubSub.DefaultConfig()) will just give you back a new instance of a Config and not do anything with it - it's an immutable object)
Peter Huang
@angrybug
Dec 10 2018 21:38
@AndreSteenbergen Suppose you have 2 web servers A and B, 1 api master X, and 1 more api master Y just joined. Server A picked up the new API master, but Server B has yet to learn of the new API master. Request 1 comes in via web server A, gets routed to API master Y. Request 2 comes in via web server B, gets routed to X. X might start working on the same URL too. Could that be the reason? I'm interested to know from the experts. In cases where correct message destination is important, e.g. a multitenancy design where we want an actor sub-tree per tenant, does consistent hashing group guarantee the message ends up at the right actor save spawning a second tree for the tenant?
Mike Bridge
@mikebridge
Dec 10 2018 22:24
@snekbaev I ended up sending the events through to the actorsystem from WebApi via an Azure EventHub. This simplifies things quite a bit---no need for a remote actor system or a cluster or anything.
Shukhrat Nekbaev
@snekbaev
Dec 10 2018 22:46
@mikebridge I'm still waiting for @Horusiath or @Aaronontheweb to reply. Meanwhile made a small PoC with akka io. It feels like it is partially replicating how remoting works. Basically, client keeps on retrying to connect to the target VM's service every 5s. When connection is established, WebApi sends messages to local actor, which internally wraps into another message, adds correlation id and stores correlation id <-> Sender mapping in the dictionary, because I need to receive a reply from VM's service. Then via json.net serialize the object and send. Receiving end deserializes it and sends to the proper actor, after processing it replies back (with correlation id) to the connection handler actor which in turn serializes back and sends to the WebApi. On WebAPI's site corresponding recepient is selected from the dictionary and message is send to it. All in all, it seems like calling code from WebAPI can still be doing the .Ask and that complexity is hidden from it. Of course I wish there was a switch to the remoting, because it's way to much boilterplate now. Also, probably, not so great custom tcp connection establish/retry related logic, plus routing and custom correlations... http would have been simpler. Maybe will rework this one day when migrate to .net core. For now just made an unvalidated assumption that TCP will be faster, given that this specific logic can be quite bursty.
Mike Bridge
@mikebridge
Dec 10 2018 23:04
@snekbaev I've managed to keep this simple by keeping state outside webapi and pushing client messages out via pusher, so it's kept the networking architecture pretty straightforward. Not sure if this is the best way to do it but putting Akka.Net in the middle to manage some weird state with nothing but event input doesn't feel too cumbersome.