Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Dec 04 23:34

    Aaronontheweb on dev

    Made cleanup call thread-safe (… (compare)

  • Dec 04 23:34
    Aaronontheweb closed #4081
  • Dec 04 23:34
    Aaronontheweb closed #4020
  • Dec 04 19:08
    Aaronontheweb commented #4079
  • Dec 04 18:35
    maratoss review_requested #4079
  • Dec 04 18:26
    maratoss synchronize #4079
  • Dec 04 07:42
    jiyeongj edited #4083
  • Dec 04 06:45
    jiyeongj opened #4083
  • Dec 04 06:35
    dependabot-preview[bot] labeled #130
  • Dec 04 06:35
    dependabot-preview[bot] opened #130
  • Dec 04 06:35

    dependabot-preview[bot] on nuget

    Bump System.Data.SqlClient from… (compare)

  • Dec 03 19:10
    Aaronontheweb synchronize #4081
  • Dec 03 19:10

    Aaronontheweb on dev

    Added async API to Akka.TestKit… (compare)

  • Dec 03 19:10
    Aaronontheweb closed #4075
  • Dec 03 19:10
    Aaronontheweb closed #3774
  • Dec 03 19:10
    Aaronontheweb closed #3854
  • Dec 03 19:10
    Aaronontheweb synchronize #4081
  • Dec 03 19:08
    IgorFedchenko commented #4020
  • Dec 03 19:03
    scptre opened #4082
  • Dec 03 18:57
    IgorFedchenko opened #4081
Bartosz Sypytkowski
@Horusiath
@themdrnsamurai it depends on how are you going to access the data inside DocumentDB - if you want to use actors as a form of smart cache, then they should either have a full authority over writing any new data to docdb or have a some sort of scheduled task that will trigger the state refresh within some time intervals.
Samurai Ken
@themdrnsamurai

@Horusiath - thanks, yeah, it sems pretty clear ideally the actor should be the sole interface to the underlying DB record. And that is with me. I just wont be able to seel converting our date purely to live within the actor state persistence store but I can se;; this.

The idea is that if, in the future, we need to interface with the data in some other way or move to another technology the data is not deeply tied to the actor implementation chosen.

Bartosz Sypytkowski
@Horusiath
you could create your own "record" object, and just bind its methods to akka actor receiviers
so actor will work as a shell around your "record" - it's pretty limiting the possibilities of particular actor model, but it's the most framework agnostic approach
Arsene
@Tochemey
Hello how do I define an Actor state that will be available during the lifetime of the actor.
Samurai Ken
@themdrnsamurai
@Horusiath I hear you on that being limiting, I am sort of hoping to avoid that (having the DocumentDB record actually act as the store for the Actor directly) it just seems liek that shoudl be wrong somehow :)
Bart de Boer
@boekabart
@Tochemey please elaborate
Bartosz Sypytkowski
@Horusiath
@Tochemey actor's fields and properties is what we call actor state
Arsene
@Tochemey

This is the code:

public class ModulesActor : ReceiveActor
    {
        private Dictionary<string, Tuple<Props, ModuleState>> _moduleRecipes;

        public ModulesActor()
        {
            Ready();
        }

        public override void AroundPreStart()
        {
            _moduleRecipes = new Dictionary<string, Tuple<Props, ModuleState>>();
        }

        public override void AroundPostStop()
        {
            _moduleRecipes = null;
        }

        protected void Ready()
        {
            Receive<LoadModules>(modules => Load());
            Receive<ModulesLoaded>(c =>
            {
                _moduleRecipes = c.Modules;
            });

            Receive<GetModuleMeta>(whois =>
            {
                Sender.Tell(GetModuleMeta(whois.ModuleName));
            });

            Receive<CheckModuleState>(state =>
            {
                Sender.Tell(GetModuleState(state.ModuleName));
            });
        }

        private ModuleState GetModuleState(string moduleName)
        {
            if (!_moduleRecipes.ContainsKey(moduleName))
                return ModuleState.NOT_IMPLEMENTED;
            return _moduleRecipes[moduleName].Item2;
        }

        protected override SupervisorStrategy SupervisorStrategy()
        {
            return new OneForOneStrategy(1,
                // maxNumberOfRetries
                TimeSpan.FromSeconds(30),
                // withinTimeRange

                exception => // localOnlyDecider
                {
                    //Error that we cannot recover from, stop the failing actor
                    if (exception is NotSupportedException) return Directive.Stop;

                    // Error related to configuration setting
                    if (exception is ConfigurationErrorsException) {
                        return Directive.Escalate;
                    }

                    //In all other cases, just stop the failing actor
                    return Directive.Stop;
                });
        }

        private ModuleMeta GetModuleMeta(string moduleName)
        {
            if (!_moduleRecipes.ContainsKey(moduleName)) return null;
            var moduleMeta = new ModuleMeta(_moduleRecipes[moduleName].Item1,
                _moduleRecipes[moduleName].Item2);
            return moduleMeta;
        }

        private static void Load()
        {
            var loader = Context.ActorOf(Props.Create(() => new ModulesLoadingActor()));
            loader.Forward(new LoadModules());
        }
    }

This is the test I am running:

        public void ModulesLoaderActorShouldReturnALoadedModule()
        {
            ActorSystemRefs.ActorSystem = Sys;
            var actorSystem = ActorSystemRefs.ActorSystem;
            var moduleManager = actorSystem.ActorOf(Props.Create(() => new ModulesActor()));
            moduleManager.Tell(new LoadModules());
            var result = ExpectMsg<ModulesLoaded>();
            Assert.NotNull(result);

            moduleManager.Tell(new CheckModuleState("mtn-gh"));
            var moduleMeta = ExpectMsg<ModuleMeta>();
            Assert.NotNull(moduleMeta);
            Assert.True(moduleMeta.State == ModuleState.ONLINE);
        }

The issue I am facing is that the moduleMeta.State does not return the expected value. The first assertion works smoothly.

Bart de Boer
@boekabart
Your manager never gets ModulesLoaded, is I think your root casue
because you forward the LoadModules, the response goes directly to the external requester. in this case, TestActor
Arsene
@Tochemey
@boekabart Any solution?
Bart de Boer
@boekabart
Tell instead of forward.
(note that your 'outer' actor won't get confirmation directly anymore)
Arsene
@Tochemey
@boekabart The reason I used forward is that I do not want to pass the SenderRef into the message.
@boekabart and the Ask-PipeTo is not too recommended in Actors.
Bart de Boer
@boekabart
yes, but you do want to the loader to respond to the manager, right?
Arsene
@Tochemey
@boekabart Yes
Bart de Boer
@boekabart
separate your 'outer contract' from your 'inner contract'
Arsene
@Tochemey
@boekabart How?
Bartosz Sypytkowski
@Horusiath
@Tochemey if ModulesLoaded is addresses specifically to manager, you don't need to check for it using ExpectMsg
Arsene
@Tochemey
Ok
However It still did not work
Bart de Boer
@boekabart
@Tochemey try drawing a sequence diagram with 'outside requester', 'manager' and 'loader' as actors
Bartosz Sypytkowski
@Horusiath
@Tochemey you either can use Ask (which is not recommended, because it's slow) or change behavior after LoadModules call
Bart de Boer
@boekabart
Ask won't work, because the manager has to update its state in the continuation (recipes)
Bartosz Sypytkowski
@Horusiath
I'll send an example in a sec
@boekabart I was talking about using Ask inside ReceiveAsync
Arsene
@Tochemey
@Horusiath So please how do I then proceed with the test code because even the code change I am now getting ModuleLoaded message instead of the expected result: This the new test code:
            ActorSystemRefs.ActorSystem = Sys;
            var actorSystem = ActorSystemRefs.ActorSystem;
            var moduleManager = actorSystem.ActorOf(Props.Create(() => new ModulesActor()));
            moduleManager.Tell(new LoadModules());
            moduleManager.Tell(new CheckModuleState("mtn-gh"));
            var moduleMeta = ExpectMsg<ModuleMeta>();
            Assert.NotNull(moduleMeta);
            Assert.True(moduleMeta.State == ModuleState.ONLINE);
Bartosz Sypytkowski
@Horusiath
@Tochemey have you applied changes from my sample gist?
Arsene
@Tochemey
@Horusiath Yes I have done that exactly.
@Horusiath A mn I am checking something
Still not working
Bartosz Sypytkowski
@Horusiath
it looks like you have Forward or Tell(..., Sender) somewhere in your ModulesActor code
Arsene
@Tochemey
@Horusiath The ModulesActor has a child Actor call ModulesLoader. Its jobs is to load the modules and returns a ModulesLoaded info to the ModulesActors. ModulesActors use forward to communicate to the child.
Bartosz Sypytkowski
@Horusiath
why are you using Forward if you need to get reply back to ModulesActor?
Arsene
@Tochemey
So what do you suggest then?
Bartosz Sypytkowski
@Horusiath
just as I've written in the sample, you can use tell and asynchronously wait for the reply
Arsene
@Tochemey
@Horusiath How I do design the test code then? I have grabbed the architecture.
Should I send Tell(LoadModules) and another Tell(CheckState)?
Bartosz Sypytkowski
@Horusiath
Test code stays the same:
            moduleManager.Tell(new LoadModules());
            moduleManager.Tell(new CheckModuleState("mtn-gh"));
            var moduleMeta = ExpectMsg<ModuleMeta>();
Garrard Kitchen
@garrardkitchen
Hi @Aaronontheweb, I wasn't able to get mono working with F# solution in windows environment so not able to tell whether the sockets error is because of mono or akka. Did any of your tyre kicking turn up anything?
Garrard Kitchen
@garrardkitchen
Hi @Aaronontheweb, I’ve now ruled out F#. Created new sln in win env and all ok but when running on mac, same error.
Garrard Kitchen
@garrardkitchen
Has anybody had success with using akka cluster (1.1.1) in docker container?
Weston
@ronnyek
whats new with akka.net in the past couple mo
are the cluster/lighthouse things working a bit more smoothly (eg, so that if lighthouse drops out after nodes discover one another, and come back in, it doesnt leave you with a cluster thats unusable?)
Garrard Kitchen
@garrardkitchen
@ronnyek cluster yes, can't comment about lighthouse as we don't use it. Before we pushed 1.1 release out we sequenced through a known set of edge cases where we knew our solution would break. Happy to say, it didn't break. Our multi-tenanted solution consists of several windows services and a few IIS sites. We tested the cluster in isolation (1 server) and over multiple servers. All good.
Arjen Smits
@Danthar
@garrardkitchen thats good to hear.
fouimette
@fouimette
blob