@object keep in mind that this one only reduces the pressure on the journal. If you are bombarding newly created actors (that didn't recover yet), they will keep stashing incoming request until their recovery completes - which in turn my cause timeouts on the sender side.
but this is most likely to happen if you have slow db and huge number of requests
Hi, I am running
ActorSystem.Terminate().Wait(); to stop my actors. Sometimes the shutdown process hangs at [DEBUG][Thread 0008][akka://MyActorSystem/user] Stopping and won't continue. Is there a way to debug what exactly is preventing the stopping?
It is an actor using the
SynchronizedDispatcher that is blocking the Terminate from proceeding. The synchronized thread seems no longer to exist. How can I kill these "dead" actors before Terminating my ActorSystem?
Strange thing observed with persistence (using PostgreSQL). On the odd occasion I have an entity, two events persisted at the same time. The events have the correct sequence number, but the ordering column has them in the wrong order. Has anyone else come across this? Any ideas as to how this can happen?
Shouldn't happen (according to docs) when Persist is called no new messages should be accepted. So basically 2 events persisted at the exact same time should be impossible.
async/ wait issue perhaps?
http://getakka.net/articles/persistence/event-sourcing.html#internal-stash Quote: The persistent actor has a private stash for internally caching incoming messages during Recovery or the Persist \ PersistAll method persisting events.
Or did you Persist 2 events during processing of 1 command?
@AndreSteenbergen It's a single command message being processed, which then persists two events. Most of the time this is fine, but on the odd occasion I see the above mentioned global ordering issue
as Persist is synchronous by nature this can sometimes occur I guess, You could Persist the second event in the Action called by the first Persist
Persist(firstEvent, evt => Persist(secondEvent, evt2 => {Handle(evt1); Handle(evt2);}) That would be the safest method
@Horusiath After reducing max-concurrent-recoveries I din't find any messages "Exceeded max-concurrent-recoveries" in our log, and with large number of parallel threads timeouts still happened. So I had to reduce the number of threads, looks like this is what triggers out persistent actors timeouts.
testing actor: should throw exception on certain condition. Test has:
this works, however, if actor's PreRestart logs the exception
EventFilter.Exception<InvalidOperationException>().ExpectOne( () => actor.Tell( toSend ) );this works, however, if actor's PreRestart logs the exception
Log.Error( reason, "PreRestart" ); then assertion fails, because it receives two InvalidOperationExceptions. Is it possible to assert only the exceptions?
same problem if logging is moved to
PostRestart
didn't expect this to work, cause logging is happening in the same actor as where exception is thrown, but this seems to solve:
EventFilter.Exception<InvalidOperationException>( source: actor.Path.ToString() ).ExpectOne( () => actor.Tell( toSend ) );
is there like an idiomatic way for me to build a HOCON config that is derived from another.
This is how one might do it in other frameworks for example
I have Config A I wanna build Config B by traversing Config A's keys building up a list of keys and values and then use those keys and values to finally derive similar Config to A but is slightly different called Config B.
dont know if im making sense
basically i want a slightly modified version of Config A without using Fallbacks
