* 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.
* keep track of delta interval versions and skip deltas
that are not consequtive, i.e. when some delta message was lost
* send the delta versions in the full state gossip to sync up the
expected versions after dropped deltas
* implementation of deltas for ORSet
* refactoring of the delta types to allow for different type for the
delta and the full state
* extensive tests
* mima filter
* performance optimizations
* simple pruning of deltas
* Java API
* update documentation
* KeyId type alias
* Use InternalApi annotation
* We used the Array based toBinary but the ByteBuffer based fromBinary.
and IntSerializer is only using the same format for those when the byte order
is LITTLE_ENDIAN, which we didn't get from protbuf's asReadOnlyByteBuffer
* We can use the Array based methods in DaemonMsgCreateSerializer,
performance is not important here
* Added some more testing in PrimitivesSerializationSpec
* #21725 cluster-sharding doesn't delete snapshots and messages
Fixes#21725
Without deleting messages those pollute persistence with not needed anymore messages. Naive and bullet proof flow is snapshot -> delete messges -> delete snapshots.
# Пожалуйста, введите сообщение коммита для ваших изменений. Строки,
# начинающиеся с «#» будут оставлены; вы можете удалить их вручную,
# если хотите. Пустое сообщение отменяет процесс коммита.
#
# Дата: Mon Oct 31 23:24:37 2016 +0300
#
# интерактивное перемещение в процессе; над 432b53c
# Последняя команда выполнена (1 команда выполнена):
# edit f86b015 21725 cluster-sharding doesn't delete snapshots and messages Fixes#21725 Without deleting messages those pollute persistence with not needed anymore messages. Naive and bullet proof flow is snapshot -> delete messges -> delete snapshots.
# Следующая команда для выполнения (1 команда осталась):
# pick 56adb40 #21725 keeping N number of batches (messages and snapshot) using N from configuration
# Вы сейчас редактируете коммит при перемещении ветки «fix-21725-delete-messages-after-snapshot» над «432b53c».
#
# Изменения, которые будут включены в коммит:
# изменено: akka-cluster-sharding/src/main/scala/akka/cluster/sharding/Shard.scala
# изменено: akka-cluster-sharding/src/main/scala/akka/cluster/sharding/ShardCoordinator.scala
#
* #21725 keeping N number of batches (messages and snapshot) using N from configuration
* Adding debug message when passivate method cannot identify entity
* Include entity in log message
* Include debug for Some where entity already being processed
* Remove manual hostname verifier support, used to be included only because Java 6 #21854
* Remove manual hostname verifier support, used to be included only because Java 6 #21854
