That can happen if you had more than one active Sharding Coordinator
writing to the same journal table, for example if you had a network
partition and used auto-downing that caused the cluster to be split into
two separate clusters. These checks are there to find this problem.
/Patrik
On Fri, Jan
I'm seeing a scenario where a cluster member is killed by Marathon due to
out of control memory growth because a persistent actor stops processing
message. When Marathon kills the cluster member the cluster role doesn't
recover due to the shard coordinators having issue. My log is full
exceptio
