+doc #17885 explain sender semantics in receiveRecover
This commit is contained in:
parent
70403446ce
commit
bce84b9b94
4 changed files with 28 additions and 0 deletions
|
|
@ -172,6 +172,11 @@ By default, a persistent actor is automatically recovered on start and on restar
|
||||||
New messages sent to a persistent actor during recovery do not interfere with replayed messages. New messages will
|
New messages sent to a persistent actor during recovery do not interfere with replayed messages. New messages will
|
||||||
only be received by a persistent actor after recovery completes.
|
only be received by a persistent actor after recovery completes.
|
||||||
|
|
||||||
|
.. note::
|
||||||
|
Accessing the ``sender()`` for replayed messages will always result in a ``deadLetters`` reference,
|
||||||
|
as the original sender is presumed to be long gone. If you indeed have to notify an actor during
|
||||||
|
recovery in the future, store its ``ActorPath`` explicitly in your persisted events.
|
||||||
|
|
||||||
Recovery customization
|
Recovery customization
|
||||||
^^^^^^^^^^^^^^^^^^^^^^
|
^^^^^^^^^^^^^^^^^^^^^^
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -174,6 +174,11 @@ By default, a persistent actor is automatically recovered on start and on restar
|
||||||
New messages sent to a persistent actor during recovery do not interfere with replayed messages.
|
New messages sent to a persistent actor during recovery do not interfere with replayed messages.
|
||||||
They are cached and received by a persistent actor after recovery phase completes.
|
They are cached and received by a persistent actor after recovery phase completes.
|
||||||
|
|
||||||
|
.. note::
|
||||||
|
Accessing the ``sender()`` for replayed messages will always result in a ``deadLetters`` reference,
|
||||||
|
as the original sender is presumed to be long gone. If you indeed have to notify an actor during
|
||||||
|
recovery in the future, store its ``ActorPath`` explicitly in your persisted events.
|
||||||
|
|
||||||
Recovery customization
|
Recovery customization
|
||||||
^^^^^^^^^^^^^^^^^^^^^^
|
^^^^^^^^^^^^^^^^^^^^^^
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -353,6 +353,19 @@ as reference::
|
||||||
// ...
|
// ...
|
||||||
}
|
}
|
||||||
|
|
||||||
|
Sender reference of replayed events is deadLetters
|
||||||
|
--------------------------------------------------
|
||||||
|
While undocumented, previously the ``sender()`` of the replayed messages would be the same sender that originally had
|
||||||
|
sent the message. Since sender is an ``ActorRef`` and those events are often replayed in different incarnations of
|
||||||
|
actor systems and during the entire lifetime of the app, relying on the existence of this reference is most likely
|
||||||
|
not going to succeed. In order to avoid bugs in the style of "it worked last week", the ``sender()`` reference is now not
|
||||||
|
stored, in order to avoid potential bugs which this could have provoked.
|
||||||
|
|
||||||
|
The previous behaviour was never documented explicitly (nor was it a design goal), so it is unlikely that applications
|
||||||
|
have explicitly relied on this behaviour, however if you find yourself with an application that did exploit this you
|
||||||
|
should rewrite it to explicitly store the ``ActorPath`` of where such replies during replay may have to be sent to,
|
||||||
|
instead of relying on the sender reference during replay.
|
||||||
|
|
||||||
Persistence Plugin APIs
|
Persistence Plugin APIs
|
||||||
=======================
|
=======================
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -158,6 +158,11 @@ By default, a persistent actor is automatically recovered on start and on restar
|
||||||
New messages sent to a persistent actor during recovery do not interfere with replayed messages.
|
New messages sent to a persistent actor during recovery do not interfere with replayed messages.
|
||||||
They are cached and received by a persistent actor after recovery phase completes.
|
They are cached and received by a persistent actor after recovery phase completes.
|
||||||
|
|
||||||
|
.. note::
|
||||||
|
Accessing the ``sender()`` for replayed messages will always result in a ``deadLetters`` reference,
|
||||||
|
as the original sender is presumed to be long gone. If you indeed have to notify an actor during
|
||||||
|
recovery in the future, store its ``ActorPath`` explicitly in your persisted events.
|
||||||
|
|
||||||
Recovery customization
|
Recovery customization
|
||||||
^^^^^^^^^^^^^^^^^^^^^^
|
^^^^^^^^^^^^^^^^^^^^^^
|
||||||
|
|
||||||
|
|
|
||||||
Loading…
Add table
Add a link
Reference in a new issue