Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Oct 20 17:25
    valdisz synchronize #3889
  • Oct 20 17:17
    valdisz synchronize #3889
  • Oct 20 15:44
    valdisz synchronize #3889
  • Oct 20 09:22
    ismaelhamed commented #3863
  • Oct 19 23:39
    valdisz synchronize #3889
  • Oct 19 23:08
    edvinasz commented #2947
  • Oct 19 13:36
    Aaronontheweb commented #3973
  • Oct 19 13:34
    dependabot-preview[bot] synchronize #3995
  • Oct 19 13:34

    dependabot-preview[bot] on nuget

    Bump BenchmarkDotNet from 0.10.… (compare)

  • Oct 19 13:34
    dependabot-preview[bot] edited #3995
  • Oct 19 13:34
    dependabot-preview[bot] synchronize #3993
  • Oct 19 13:34

    dependabot-preview[bot] on nuget

    Bump Google.Protobuf from 3.9.1… (compare)

  • Oct 19 13:34
    dependabot-preview[bot] synchronize #3991
  • Oct 19 13:34

    dependabot-preview[bot] on nuget

    Bump Microsoft.Extensions.Depen… (compare)

  • Oct 19 13:34
    dependabot-preview[bot] synchronize #3989
  • Oct 19 13:34

    dependabot-preview[bot] on nuget

    Bump ApiApprover from 3.0.1 to … (compare)

  • Oct 19 13:34
    dependabot-preview[bot] synchronize #3992
  • Oct 19 13:34
    dependabot-preview[bot] edited #3993
  • Oct 19 13:34
    dependabot-preview[bot] synchronize #3985
  • Oct 19 13:34

    dependabot-preview[bot] on nuget

    Bump System.Reflection.Emit fro… (compare)

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.
this is also a case for event journals and snapshot stores
Andrey Leskov
@andreyleskov
ok, so only plugins can be loaded later?
Bartosz Sypytkowski
@Horusiath
(also event journal is called by every persistent actor, when it's instantiated)
what do you mean by "only plugins"?
Andrey Leskov
@andreyleskov
I mean akka core parts are ready, and only extensions can be not ready just after system was created
Long story to short I have SpecFlow tests and have to recreate ActorSystem on each.
Had an issue when tests worked only when launched separately - reason was Stop not had been awaited
Trying to understand if I should wait for something after system creation, when test just starts
Bartosz Sypytkowski
@Horusiath
akka core parts are run right away, but core is very ligthweight (remember, that remote, cluster and persistence are all plugins). Nonetheless when you're using something it will be initialized.
btw. are you telling, you're using SpecFlow with actor system but does that mean you don't use testkit?
Andrey Leskov
@andreyleskov
Yes, I don't use TesKit in specFlow as it is used for acceptance tests with calling controllers and other hi-level staff
For sure there are a bunch of unit tests inherited from TestKit
Andrey Leskov
@andreyleskov
@Horusiath thanks for your time! You've helped me a lot !
Bartosz Sypytkowski
@Horusiath
np ;)
TI-85, Azure VM
same thing
Andrey Leskov
@andreyleskov
)) welcome to Azure, great cloud but sometimes weird
Maciek Misztal
@mmisztal1980
lol
Aaron Stannard
@Aaronontheweb
@andreyleskov agreed
I'm still deleting hundreds of resource groups TeamCity created on-demand by accident a couple of months back when we were working on the CI system
cloud equivalent of toxic waste removal
@Silv3rcircl3 so it looks like that TeamCity formatting for NBench has found the worst offender already for the Akka.Streams.Tests.Performance specs
Performance.JsonFramingBenchmark+Counting_1
Performance.JsonFramingBenchmark+Counting_offer_5
looks like some issue where the minimum throughput can vary a lot (yay concurrency on preemptive operating systems)
Failed at least one assertion or threw exception.

------- Stdout: -------
DATA
[Counter] Bracket: Max: 7,973.00 operations, Average: 7,973.00 operations, Min: 7,973.00 operations, StdDev: 0.00 operations
[Counter] Bracket: Max / s: 16,441.10 operations, Average / s: 15,850.27 operations, Min / s: 13,593.64 operations, StdDev / s: 879.99 operations
ASSERTIONS
------- Stderr: -------
[FAIL] Expected [Counter] Bracket to must be greater than 20,000.00 operations; actual value was 15,850.27 operations.
Aaron Stannard
@Aaronontheweb
I haven't looked at the spec itself yet, but given that the number of operations is identical I'm assuming this is written as a RunMode = ThroughPut spec, right?
what can end up happening there.... interesting... this is actually probably a design issue with NBench!
if the first warmup we use, for estimating roughly how many iterations it takes to execute in whatever the duration is you specify, is really slow
which it usually is given that that's when all of the code gets JITed
then the maximum number of iterations the system executes is always going to be fairly low
for each of the benchmark runs