* Possibility to prefer oldest in ddata writes and reads
* enabled for Cluster Sharding
* New ReadMajorityPlus and WriteMajorityPlus
* used by Cluster Sharding, with configuration
* also possible to define ReadAll in config
* sometimes failed: "WriteAggregator with delta must timeout when less than required acks"
* the DeltaNack will trigger immedediate send of Write
* seems to be a race condition of when the probe is receiving the Write
from the DeltaNack vs the last expected DeltaPropagation
* The scenario was (probably) that a node was restarted with
same host:port and then didn't join the same cluster. The DData
Replicator in the original cluster would continue sending messages
to the new incarnation resulting in false removals.
* The fix is that DData Replicator includes the system uid of the sending
or target system in messages and if recipient gets a message that is from/to
unknown it will discard it and thereby not spreading information across
different clusters.
* Reproduced in ClusterReceptionistSpec
* Much hardening of other things in ClusterReceptionistSpec
* There are also some improvements to ClusterReceptionist to not leak
Listing with refs of removed nodes.
* use ClusterShuttingDown
* The reason for using sender system uid instead of target uid in messages
like Read and Write is that then the optimization for sending same message
to many destinations can remain.
* ⇒, →, ←
* because we don't want to show them in documentation snippets and
then it's complicated to avoid that when snippets are
located in src/test/scala in individual modules
* dont replace object `→` in FSM.scala and PersistentFSM.scala
* Add CopyrightHeader support for sbt-boilerplate plugin.
* Add CopyrightHeader support for `*.proto` files.
* Add regex match for both `–` and `-` for CopyrightHeader.
* Add CopyrightHeader support for sbt build files.
* Update copyright from 2018 to 2019.
* Follow up on the causal delivery of deltas.
* The first implementation used full state for the direct
Write messages, i.e. updates with WriteConsistency != LocalWrite
* This is an optimization so that delatas are tried first and if
they can't be applied it falls back to full state.
* For simultanious updates the messages may be reordered because we
create separate WriteAggregator actor and such, but normally they
will be sent in order so the deltas will typically be received in
order, otherwise we fall back to retrying with full state in the
second round in the WriteAggregator.
* Provide shorter aliases for the ActorRefProviders #20649
* Use the new actorefprovider aliases throughout code and docs
* Cleaner alias replacement logic
The WriteAggregator and ReadAggregator typically send
the same message to several replicas and by caching the serialized bytes
we avoid doing the same thing for each message
and add a test for WriteAggregator
