+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
|
||||
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
|
||||
^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
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
|
||||
^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
=======================
|
||||
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
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
|
||||
^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue