Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • 19:13
    hwanders commented #4096
  • 13:05
    IgorFedchenko commented #4085
  • 03:08
    hhko commented #4094
  • Dec 13 21:37
    Aaronontheweb commented #4085
  • Dec 13 20:28
    IgorFedchenko commented #4085
  • Dec 13 20:27
    IgorFedchenko commented #4085
  • Dec 13 15:38
    Aaronontheweb labeled #4096
  • Dec 13 15:38
    Aaronontheweb milestoned #4096
  • Dec 13 15:38
    Aaronontheweb labeled #4096
  • Dec 13 15:38
    Aaronontheweb opened #4096
  • Dec 13 10:41
    peirens-bart opened #4095
  • Dec 13 08:37
    Aaronontheweb synchronize #4071
  • Dec 13 08:13
    jiyeongj opened #4094
  • Dec 12 15:42
    Aaronontheweb synchronize #4086
  • Dec 12 15:42
    Aaronontheweb closed #4083
  • Dec 12 15:42

    Aaronontheweb on dev

    Fix #4083 - Endpoint receive bu… (compare)

  • Dec 12 15:42
    Aaronontheweb closed #4089
  • Dec 12 15:42
    Aaronontheweb labeled #4093
  • Dec 12 15:42
    Aaronontheweb labeled #4093
  • Dec 12 15:42
    Aaronontheweb labeled #4093
Aaron Stannard
@Aaronontheweb
the concurrent programming version of the observer effect :p
Sean Farrow
@SeanFarrow
@aaronontheweb is that just on the server or building locally as well
Aaron Stannard
@Aaronontheweb
@SeanFarrow building locally it's worked fine for the most part. We had issues on the server where the time-sensitive Akka.Streams NBench specs would fail
5ms deadlines on some of them
Aaron Stannard
@Aaronontheweb
blob
there we go
we're going to be adding this to the Multi node test runner as well
that'll allow TeamCity's "flaky tests" report to help signal to us where we need to go spend some time hardening stuff
the benchmarking stuff is a bit harder to fix mostly because benchmarking concurrent code is a dark art
we do things like toggle the processor priority to help it get scheduled ahead of everything else, but we're still at the mercy of the OS when it comes to that
in the grand scheme of things, relativistic benchmarking is the way to solve that
build up a history of every benchmark run for the same hardware profile and judge any new benchmark relative to the old ones
and use an estimated weighted moving average or some sort of threshold system to determine if a new change is seriously out of line or not
but that requires storing the state somewhere and adding a bunch of fun network calls to the assertion engine NBench uses
and better hardware finger printing
Aaron Stannard
@Aaronontheweb
next thing happening to NBench is .NET Core support; after we're tied to the constraints of what .NET Core does (i.e. no more performance counters,) we can come up with a strategy that will work X-plat
question for someone in the room: any Unity3D programmers in here? what's going on with their .NET version roadmap? https://unity3d.com/unity/roadmap
Still on .NET 2.0?
Andrey Leskov
@andreyleskov
Hi all. I'm looking for saving snapshot after all of produced events persistence
from docs I've found DeferAsync method
but it will be called after first scheduled PersisteAsync
I'm using PersistAll, so DeferAsync will be called many times
how can I call a method after all of events been persisted?
Bartosz Sypytkowski
@Horusiath
@andreyleskov DeferAsync works in combination with PersistAsync, but it's not necessary for Persist itself. Also Persist takes callback to be called, when event persist will be confirmed
Andrey Leskov
@andreyleskov

@Horusiath
I had a code:

 var events = CurrentState.Change();
 PersistAll(events, e => Publisher.Publish(e));
 SaveSnapshot(CurrentState);

And it produce invalid snapshots sometimes - it cannot be restored from persisted events. I assume some of events can be lost.
So I'm looking for a way to save snapshot after all events will be persisted, not just one.
Now switched to

 var events = CurrentState.Change();
 PersistAll(events, e => Publisher.Publish(e));
var state  = CurrentState;
Defer(state, s => SaveSnapshot(s));
May be this is a stupid problem but I can't figure out better solution from documentation 8 (
Bartosz Sypytkowski
@Horusiath
@andreyleskov standard approach is to save snapshot every X events persisted. Snapshots are used only as optimization in case when event stream for persistent actor gets long, and may be time consuming to replay
Andrey Leskov
@andreyleskov
@Horusiath yes, and I'm using it exact for this purpose ) Just removed code that decide how often we should save snapshots. Do you mean it is better to switch to
PersistAll ( events, e => { 
if(Decider.ShouldSave(e))
   SaveSnapshot(CurrentState);
});
Bartosz Sypytkowski
@Horusiath
yep, there's an important thing here to remember
Persist callback is invoked after event has been persisted and (along with Recovery handler) should be the only place, when you're updating actor's persistent state
otherwise you may change a state of an actor, send persist event that will never succeed, in the meantime save (successfully) a snapshot of the current state, and end up with split/corrupted state of an actor
Bartosz Sypytkowski
@Horusiath
also there is no guarantee that your actor will try to recover from the last snapshot, you've ordered to save (as it might have been not yet been confirmed, when actor restarted)
Andrey Leskov
@andreyleskov
ok, thank you a lot !
Andrey Leskov
@andreyleskov

@Horusiath I'm using approach:

Receive<ICommand>(c => {
  var events = Aggregate.ExecuteCommand(c);
  PersistAll( events);
});

So state is changed before persist, but inside one command method, I'm rely on one-command-in-time actors behaviour

Bartosz Sypytkowski
@Horusiath
@andreyleskov what if the events won't be persisted? Your state will differ from what actually has been stored in the database.
Andrey Leskov
@andreyleskov
yeah, I see the problem 8 (
will inject Persist into Aggregate itself
Andrey Leskov
@andreyleskov
@Horusiath if event will not be saved, persistent actor will be stopped, according to documentation: "If persistence of an event fails, OnPersistFailure will be invoked (logging the error by default), and the actor will unconditionally be stopped."
and PersistAll says it will block all incoming messages
Can you please give an example when we can leak state in code above ?

and for me it makes sequence of:

start execute command (Receive)
mutate state (var events = Aggregate.ExecuteCommand(e))
save events (PersistAll)

atomic - while we are in Receive block, no other command can be processed, when we are saving via PersistAll, no other command can be processed

Bartosz Sypytkowski
@Horusiath
I don't know you you managed to get Receive method while using persistent actor ;)
Andrey Leskov
@andreyleskov
My bad >_< It should be Command<> instead of Receive<>
Bartosz Sypytkowski
@Horusiath
np ;) I need to check something
yep, I don't know if this is in the docs, but there a situation called event rejection - event journal may decide to reject persisting events, which will eventually trigger OnPersistRejected method, but this won't cause actor to stop
Andrey Leskov
@andreyleskov
yes, it is in docs : "If persistence of an event is rejected before it is stored, e.g. due to serialization error, OnPersistRejected will be invoked (logging a warning by default), and the actor continues with the next message."
Is there any other case than serialization? Because I greatly believe in journal correct work ))
Bartosz Sypytkowski
@Horusiath
persistence compatibility testkit doesn't ensure that it will happen only upon serialization. So I wouldn't assume that an implementation you're using will reject only on serialization errors
tbh. I think, I might have not checked that behavior in new sql batching journal impl
Andrey Leskov
@andreyleskov
one more question - when ActorSystem.Create() returns an ActorSystem, is it fully ready to function ? Do we need to wait for something ? For a example ActorSystem.Stop() returns a Task, so it is suspicious that Start does not have a Task
Bartosz Sypytkowski
@Horusiath
no, when actor system starts it didn't have to load all plugins. Some of them are loaded lazily, when called.