Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • May 07 18:06
    Aaronontheweb commented #3790
  • May 07 08:12
    dependabot[bot] labeled #4999
  • May 07 08:12
    dependabot[bot] opened #4999
  • May 07 08:12

    dependabot[bot] on nuget

    Bump Google.Protobuf from 3.15.… (compare)

  • May 07 01:13
    Aaronontheweb commented #3790
  • May 06 23:45
    Aaronontheweb synchronize #3790
  • May 06 23:45

    Aaronontheweb on dev

    Prevent loggers to throw Format… (compare)

  • May 06 23:45
    Aaronontheweb closed #4908
  • May 06 23:45
    Aaronontheweb closed #4998
  • May 06 23:45
    Aaronontheweb auto_merge_disabled #4998
  • May 05 18:08
    Aaronontheweb labeled #4998
  • May 05 18:08
    Aaronontheweb labeled #4998
  • May 05 18:08
    Aaronontheweb labeled #4998
  • May 05 18:08
    Aaronontheweb labeled #4998
  • May 05 18:08
    Aaronontheweb milestoned #4998
  • May 05 18:08
    Aaronontheweb auto_merge_enabled #4998
  • May 05 16:36
    Aaronontheweb synchronize #4119
  • May 05 16:27
    Arkatufus synchronize #3790
  • May 05 15:48
    Arkatufus synchronize #3790
  • May 05 15:41
    Aaronontheweb commented #3790
Christian Duhard
@cduhard
the current passivation timer waits for those sagas to play out, e.g skips passivation if there are any in progress
Bartosz Sypytkowski
@Horusiath
then you can create your custom PoisonPill equivalent, that can be rejected or delayed due to saga being in progress
Christian Duhard
@cduhard
but then I still have to wait
I don't need to build that because I can just wait for them to passivate. there are no new messages coming in. the shutdown has cut that off further up the hierarchy
Bartosz Sypytkowski
@Horusiath
you can wait for termination
Christian Duhard
@cduhard
yes, I need to know when all are terminated
so i can move forward
a timer is just as easy as trying to keep track of what's alive etc
not as precise, but far less complex
if i were to cluster & shard this I would do this in a more robust way
am I making sense?
Bartosz Sypytkowski
@Horusiath
why you thing that handling Terminated is more complex?
Christian Duhard
@cduhard
there is a disconnect here
i need to know when all of them are terminated
i can't do anything until that happems
*happens
they terminate without the app being in shutdown
Bartosz Sypytkowski
@Horusiath
...
  // normal receive
  message.Match()
  .With<Shutdown>(shutdown =>{
    var accounts = Context.GetChildren().Select(aref => aref.Path.Name.Contains("account")).ToArray();
    foreach(var account in accounts) account.Tell(shutdown);
    Become(WaitingForTermination(accounts.Length))
  });
}

public Receive WaitingForTermination(int counter) {
  var remaining = counter;
  return message => message.Match()
    .With<Terminated>(terminated => {
        if(terminated.ActorRef.Path.Name.Contains("account"))
          remaining--;
        if(remaining == 0)
          AllAccountsTerminated();
    })
    .WasHandled;
}
Christian Duhard
@cduhard
yeah, we were almost identical except I would just poll which is shite, but i was ok with it. My solution requires no changes to the Persistent actor with the down side of a timer
@Horusiath thanks a lot though. I am the only one doing message based work here, I have no one to bounce this stuff off of
Bartosz Sypytkowski
@Horusiath
no problem :)
Christian Duhard
@cduhard
do you have tests for that code?
j/k ;)
@Horusiath regarding your sharding persistence app, the intention is for you sagas to continue on restart correct?
Bartosz Sypytkowski
@Horusiath
at some point, once it will be finished
Christian Duhard
@cduhard
that's cool, i wanted to do that, but didn't have the time to reason through it. your sample makes it straightforward
Bartosz Sypytkowski
@Horusiath
sagas are hard once you apply "what if something will crash at any point in time" approach
Christian Duhard
@cduhard
yes they are, that's where I said, maybe later
can I use become from ActorBase?
Bartosz Sypytkowski
@Horusiath
yes
Christian Duhard
@cduhard
Used the same way? I only have an override of Receive.
Bartosz Sypytkowski
@Horusiath
Context.Become with Receive delegate
Christian Duhard
@cduhard
Context.Become(WaitingForTermination(accounts.Length));
Bartosz Sypytkowski
@Horusiath
yes
but if your have actor based on ReceiverActor or it's persistent version, you won't need much to adjust the sample to work with
Christian Duhard
@cduhard
is there any reason to use this style over Match?
                else if (message is Shutdown)
                {        
            var m = message as Shutdown;
Bartosz Sypytkowski
@Horusiath
no, just convinience
Christian Duhard
@cduhard
i just left some of it from your original sample. I much prefer Match syntax
Bartosz Sypytkowski
@Horusiath
with C# 7 we'll have pattern matching, and all of this will be part of language syntax
Christian Duhard
@cduhard
i was just going to say we need pattern matching
not sure why they didn;t include it in 6
so C# is becoming scala with readable syntax
Bartosz Sypytkowski
@Horusiath
still far from it ;) less expressive type system, no macros etc. also less "magic" ;)
Christian Duhard
@cduhard
i don't like scala syntax
it feels like a mess
Bartosz Sypytkowski
@Horusiath
some parts are nice, some are wtf
like with almost any language
Christian Duhard
@cduhard
the nice things about C# is they've done a pretty good job adding cool language features relatively cleanly
some better shorthand for list manipulation would be nice
they should also alias standard things like map, fold etc