remember entities and changing shardIdExtractor (#22894)

* Test case covering changing shard id extractor with remember-entities

* This should do the trick

* Feedback addressed

* Docs and migration guide mention

* Correct logic to persist that entity has moved off off shard
This commit is contained in:
Johan Andrén 2017-05-22 10:08:18 +02:00 committed by Patrik Nordwall
parent 601024dfe0
commit 86aa42cf6c
11 changed files with 1648 additions and 35 deletions

View file

@ -267,12 +267,15 @@ are thereafter delivered to a new incarnation of the entity.
The list of entities in each `Shard` can be made persistent (durable) by setting
the `rememberEntities` flag to true in `ClusterShardingSettings` when calling
`ClusterSharding.start`. When configured to remember entities, whenever a `Shard`
is rebalanced onto another node or recovers after a crash it will recreate all the
entities which were previously running in that `Shard`. To permanently stop entities,
a `Passivate` message must be sent to the parent of the entity actor, otherwise the
entity will be automatically restarted after the entity restart backoff specified in
the configuration.
`ClusterSharding.start` and making sure the `shardIdExtractor` handles
`Shard.StartEntity(EntityId)` which implies that a `ShardId` must be possible to
extract from the `EntityId`.
When configured to remember entities, whenever a `Shard` is rebalanced onto another
node or recovers after a crash it will recreate all the entities which were previously
running in that `Shard`. To permanently stop entities, a `Passivate` message must be
sent to the parent of the entity actor, otherwise the entity will be automatically
restarted after the entity restart backoff specified in the configuration.
When [Distributed Data mode](#cluster-sharding-mode) is used the identifiers of the entities are
stored in @ref:[Durable Storage](distributed-data.md#ddata-durable) of Distributed Data. You may want to change the

View file

@ -270,12 +270,15 @@ are thereafter delivered to a new incarnation of the entity.
The list of entities in each `Shard` can be made persistent (durable) by setting
the `rememberEntities` flag to true in `ClusterShardingSettings` when calling
`ClusterSharding.start`. When configured to remember entities, whenever a `Shard`
is rebalanced onto another node or recovers after a crash it will recreate all the
entities which were previously running in that `Shard`. To permanently stop entities,
a `Passivate` message must be sent to the parent of the entity actor, otherwise the
entity will be automatically restarted after the entity restart backoff specified in
the configuration.
`ClusterSharding.start` and making sure the `shardIdExtractor` handles
`Shard.StartEntity(EntityId)` which implies that a `ShardId` must be possible to
extract from the `EntityId`.
When configured to remember entities, whenever a `Shard` is rebalanced onto another
node or recovers after a crash it will recreate all the entities which were previously
running in that `Shard`. To permanently stop entities, a `Passivate` message must be
sent to the parent of the entity actor, otherwise the entity will be automatically
restarted after the entity restart backoff specified in the configuration.
When [Distributed Data mode](#cluster-sharding-mode) is used the identifiers of the entities are
stored in @ref:[Durable Storage](distributed-data.md#ddata-durable) of Distributed Data. You may want to change the

View file

@ -479,6 +479,18 @@ Note that the stored @ref:[Remembering Entities](../cluster-sharding.md#cluster-
be migrated to the `data` mode. Such entities must be started again in some other way when using
`ddata` mode.
### Cluster Sharding remember entities
To use *remember entities* with cluster sharding there are now an additional requirement added: the
`extractShardId` must be able to extract the shard id from the message `Shard.StartEntity(EntityId)`.
This is implies that it must be possible to calculate a shard id from an entity id when using remember
entities.
This was added to be able to gracefully handle when persisted locations of entities does not match
where the entities should live when a shard region starts up. Such states could be cause by changing
the `extractShardId` logic and restart a system using *remember entities*.
### Cluster Management Command Line Tool
There is a new cluster management tool with HTTP API that has the same functionality as the command line tool.