* It was a timing race condition in the test that was exposed
by the change in PR #25315. Full state is now sent immediately
when receiving the DeltaNack and that makes the Update complete
much faster for that case than before.
* That resulted in that the delta propagations from previous
updates were still in the buffer to be sent out when the
incr(4) was performed. Those deltas contained the NoDeltaPlaceholder,
which caused the inrc(4) delta to also be folded into NoDeltaPlaceholder
and thereby not propagated.
* Before the DeltaNack the buffer had time to be flushed before the incr(4)
and therefore no NoDeltaPlaceholder.
* Use deterministic order of the target nodes for the writes when
type RequiresCausalDeliveryOfDeltas, otherwise the random pick
of targets caused that delta sequence numbers were missing for
susequent updates
* Resend immediately when receiving DeltaNack instead of waiting
for timeout. DeltaNack can happen when there are multiple
concurrent updates from same node because each starts a WriteAggregator
and a later Update might bypass an earlier
* The ThreadLocal Serialization.currentTransportInformation is used for serializing local
actor refs, but it's also useful when a serializer library e.g. custom serializer/deserializer
in Jackson need access to the current ActorSystem.
* We set this in a rather ad-hoc way from remoting and in some persistence plugins, but it's only
set for serialization and not deserialization, and it's easy for Persistence plugins or other
libraries to forget this when using Akka serialization directly.
* This change is automatically setting the info when using the ordinary serialize and deserialize
methods.
* It's also set when LocalActorRefProvider, which wasn't always the case previously.
* Keep a cached instance of Serialization.Information in the provider to avoid
creating new instances all the time.
* Added optional Persistence TCK tests to verify that the plugin is setting this
if it's using some custom calls to the serializer.
* since the ordering can change based on the member's status
it's not possible to use ordinary - for removal
* similar issue at a few places where ageOrdering was used
* Sharding only within own team (coordinator is singleton)
* the ddata Replicator used by Sharding must also be only within own team
* added support for Set of roles in ddata Replicator so that can be used
by sharding to specify role + team
* Sharding proxy can route to sharding in another team
* to avoid OversizedPayloadException
* some complex deltas grow for each update operation, e.g.
when updating different keys in ORMap (PNCounterMap)
* such large deltas can safely be discarded and disseminated as full
state instead
* added ReplicatedDeltaSize interface to be able to define the "size"
and when that size exceeds configured threshold the delta is discarded
* Lazy init of LmdbDurableStore, #22759
* to avoid creating files (and initializing db) when not needed,
e.g. cluster sharding that is not using remember entities
* enable MiMa against 2.5.0
* use OptionVal instead
When a DeltaReplicatedData returns None from delta it must still be
treated as a delta that increase the version counter in DeltaPropagationSelector.
Otherwise a later delta might be applied before the full state gossip is received
and thereby violating RequiresCausalDeliveryOfDeltas.
* 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.
