+doc #17885 explain sender semantics in receiveRecover

This commit is contained in:
Konrad Malawski 2015-07-01 17:00:11 +02:00
parent 70403446ce
commit bce84b9b94
4 changed files with 28 additions and 0 deletions

View file

@ -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
^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^

View file

@ -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
^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^

View file

@ -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
======================= =======================

View file

@ -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
^^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^