Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Oct 18 19:12
    IgorFedchenko commented #3998
  • Oct 18 18:29
    Aaronontheweb commented #3998
  • Oct 18 18:24
    Aaronontheweb opened #3998
  • Oct 18 18:19

    Aaronontheweb on fix-readme-logo

    (compare)

  • Oct 18 17:30
    Aaronontheweb milestoned #3973
  • Oct 18 16:38
    jaydeboer opened #3997
  • Oct 18 15:53
    Aaronontheweb synchronize #3973
  • Oct 18 15:52

    dependabot-preview[bot] on dev

    Bump Microsoft.NET.Test.Sdk fro… (compare)

  • Oct 18 15:52

    dependabot-preview[bot] on nuget

    (compare)

  • Oct 18 15:52
    dependabot-preview[bot] closed #3996
  • Oct 18 15:52
    Aaronontheweb commented #3996
  • Oct 18 14:53
    Aaronontheweb commented #3973
  • Oct 18 12:20
    IgorFedchenko commented #3973
  • Oct 18 12:17
    IgorFedchenko commented #3973
  • Oct 18 11:58
    IgorFedchenko synchronize #3973
  • Oct 18 11:33
    IgorFedchenko commented #3973
  • Oct 18 11:25
    IgorFedchenko synchronize #3973
  • Oct 18 07:04
    dependabot-preview[bot] labeled #3996
  • Oct 18 07:04
    dependabot-preview[bot] opened #3996
  • Oct 18 07:04

    dependabot-preview[bot] on nuget

    Bump Microsoft.NET.Test.Sdk fro… (compare)

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
hence why the maximum value, let alone the average value, didn't make it above your threshold here
we should probably not blindly rely on the very first run to estimate how many iterations it takes to fill a second
rather run a few of them and discard the first value, knowing that JIT plays a factor there
essentially this bug means we never generate a sample size that's sufficiently large
if the "estimator" round for a throughput spec has a ton of overhead
does that make sense?