Repository navigation
Better recovery timeout for persistent actors #20738 - #20753
johanandren merged 5 commits into
Conversation
akka-ci
added
validating
|
Test PASSed. |
| new State { | ||
|
|
||
| // protect against snapshot stalling forever because of journal overloaded and such | ||
| val timeout = extension.journalConfigFor(journalPluginId).getMillisDuration("recovery-event-timeout") |
There was a problem hiding this comment.
perhaps pass as a param, to avoid reading the config twice
There was a problem hiding this comment.
Could I even put it in a place so it doesn't have to be read once per persistent actor start?
There was a problem hiding this comment.
You can't put it in the trait because that would break bin compat.
We could change journalConfigFor to return a Settings object that would read such things once, but I don't think it's worth it. It's rather costly to start a persistent actor anyway.
| } | ||
| case RecoverySuccess(highestSeqNr) ⇒ | ||
| resetRecieveTimeout() | ||
| timeoutCancellable.cancel() |
There was a problem hiding this comment.
there is a small chance that a RecoveryTick is already enqueued in the mailbox here and will be delivered to user's receive. That could be filtered out innProcessingState or at least ignored in unhandled.
There was a problem hiding this comment.
Ah, yes, I was going to ask about that. Will look into it.
|
LGTM |
1 similar comment
|
LGTM |
|
|
||
| case _: RecoveryTick => | ||
| // we may have one of these scheduled before the scheduled timeout | ||
| // is cancelled, just consume it so the concrete actor never sees it |
There was a problem hiding this comment.
that was weird phrasing, will redo
akka-ci
added
validating
|
Test PASSed. |
| private final case class AsyncHandlerInvocation(evt: Any, handler: Any ⇒ Unit) extends PendingHandlerInvocation | ||
|
|
||
| /** message used to detect that recovery timed out */ | ||
| private case class RecoveryTick(snapshot: Boolean) |
|
LGTM |
akka-ci
added
validating
|
Test PASSed. |
4 participants
Fixes #20738 by using the scheduler instead of
receiveTimeoutadditionally it will therefore not be affected by non-recovery messages passing by into the stash of the persistent actor.