Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Oct 17 22:42
    Aaronontheweb commented #3944
  • Oct 17 22:41
    Aaronontheweb commented #3973
  • Oct 17 21:17
    IgorFedchenko commented #3973
  • Oct 17 21:08
    IgorFedchenko commented #3973
  • Oct 17 19:59
    IgorFedchenko synchronize #3973
  • Oct 17 19:34
    IgorFedchenko synchronize #3973
  • Oct 17 16:12
    Aaronontheweb commented #3993
  • Oct 17 15:51
    dependabot-preview[bot] synchronize #3991
  • Oct 17 15:51

    dependabot-preview[bot] on nuget

    Bump Microsoft.Extensions.Depen… (compare)

  • Oct 17 15:51
    dependabot-preview[bot] synchronize #3989
  • Oct 17 15:51

    dependabot-preview[bot] on nuget

    Bump ApiApprover from 3.0.1 to … (compare)

  • Oct 17 15:51
    dependabot-preview[bot] edited #3991
  • Oct 17 15:51
    dependabot-preview[bot] edited #3989
  • Oct 17 15:51
    dependabot-preview[bot] synchronize #3985
  • Oct 17 15:51

    dependabot-preview[bot] on nuget

    Bump FsCheck.Xunit from 2.9.0 t… (compare)

  • Oct 17 15:51
    dependabot-preview[bot] edited #3985
  • Oct 17 15:51
    dependabot-preview[bot] synchronize #3982
  • Oct 17 15:51

    dependabot-preview[bot] on nuget

    Bump FsPickler from 5.2.0 to 5.… (compare)

  • Oct 17 15:51
    dependabot-preview[bot] synchronize #3986
  • Oct 17 15:51
    dependabot-preview[bot] synchronize #3983
Zetanova
@Zetanova
(Created+Updated)
I removed now the locks from the DBSnapotStore and getting again the Error at PendingOperations.Remove(tokenSource);
in the LoadAsync method
Zetanova
@Zetanova
wahahahah
PipeTo is not waiting to complition
This message was deleted
=> Concurrent execution in the Snapshot Actor
Zetanova
@Zetanova
LoadAsync() => sawns a new thread (or takes one from the pool)
PipeTo is just execution on the same new thread and the end
if 10 messages are comming
then there will be lots of simultan executoon inside the actor
Bartosz Sypytkowski
@Horusiath
in case of snapshot actor this shouldn't be a problem
Zetanova
@Zetanova
if this execution has some side effect, it is most likly a race condition
sure it is
if an PA is taking two snapshots
at the same time
it is allready possible that the first is saved after the second
Bartosz Sypytkowski
@Horusiath
if you have events: a-1, a-2, a-3, a-4 and snapshots at the moment of a-1 and a-3, for the sake of consistency it doesn't matter which snapshot will it receive
if it will receive snapshot a-1, it will startup at point of a-1 and recover from events a-2 to the end of the stream
if it will receive snapshot a-3 it will use only event a-4 and above to recover
Zetanova
@Zetanova
thats clear in the Snapshot store
Bartosz Sypytkowski
@Horusiath
or you are using words snapshots and events interchangeably
Zetanova
@Zetanova
I removed the lock i insered on PendingOperations
because i thought it is not required
but its in parallel execution because of this PipeTo
Bartosz Sypytkowski
@Horusiath
but if you're talking about event batches, this also shouldn't happen, as persistent actor won't emit second batch of messages to the journal until it receives confirmation about successfully stored first one
Zetanova
@Zetanova
then its fine
Horusiath @Horusiath enough for today, time to sleep
Zetanova
@Zetanova
gn8
Zetanova
@Zetanova
good morning
i tought about this PipeTo pattern thats creates basicly a free concurrent operation in the actor.
If it schould be supported, then there schould be some kind of operation manager in the ActorBase
So that the developer is forced to declare the execution mode.
One Modes would be the free asynchrone background thread, It schould be with cancelation support like in the DbSnapshot Actor with pendingOperations
Zetanova
@Zetanova
and One Mode that the Task schould completed before the next message of the actor can be processed like the RunTask() in the ReciverActor behaivior
The first mode would be a background thread that can basicly be awaited or canceled on PreStop of the actor
the second mode is basicly a Task.WhenAll() then NextMessage
Zetanova
@Zetanova
But currently this StartOperationAsync().PipeTo(Sender) is a fire and forget approach, very missleading and lose of control. If the Async Method is outside of the actor then the side effect of it will not have much impact. But if it is used with a AsyncMethod inside the actor then the side effect will have most propaly a big role.
Zetanova
@Zetanova
If MessageA creates a background task with PipeTo()
then MessageA+PoisonPill should await this task
and MessageA+Kill should try to cancel it and then stop
Zetanova
@Zetanova
Currently the system is only running because the message is reporcessed on Restart of a failed actor.
if MessageA creates this Background Thread with PipeTo() and a following arraivle of the messageA will generate a race-condition and exception (like Linklist.Remove())
Zetanova
@Zetanova
the first messageA will be STILL processed on incanation-1 and the second message will then be parallel processed in incanation-2, thats a very bad behaivior.
Bartosz Sypytkowski
@Horusiath
@Zetanova I really like this kind of interest in the project. It's very motivating ;)
Bartosz Sypytkowski
@Horusiath
the major problem is not behavior of PipeTo itself, but rather this specific implementation. In general you should never mutate actor state inside called tasks - if you do, you basically violate one of the core principles of actor model (messages are processed synchronously). As long as this principle applies, actors are free of race conditions, and this is a behavior we want to remain. Async can be called sometimes - usually for interop or controlled cancelations - but in this case it should never touch mutable data to modify it.
Zetanova
@Zetanova
@Horusiath I am very sure that i receive two times the persistent events on ReceiveRecover
but they are stored only once
Bartosz Sypytkowski
@Horusiath
could you manage to provide some snippet with this issue?
Zetanova
@Zetanova
not realy
its near the same position / AR