* assertion failed: Nodes not part of cluster have marked the Gossip as seen
* trying to mark the Gossip as seen before it has joined, which may happen
if CoordinatedShutdown is running before the node has joined
* it was logging "No match found for command of type [akka.cluster.sharding.typed.javadsl.ClusterShardingPersistenceTest$StopPlz]"
* StopPlz not used in that test
* Move 'Remoting' under 'Clustering' in the docs #26491
* As it is typically not used directly, but as an implementation detail of
Clustering.
* Warn when remoting is used directly #26491
* Remove akka-camel
This module has been deprecated since 2.5.0 and will now be removed in 2.6.
If there is interest it can be moved to a separate community-maintained repo.
* Add note to migration guide
* Remove from allModules as well
* Attempt to fix multi-jvm failure when untyped system is adapted from typed system
Spawn system space actors instead of user space in multi-jam
* Attempt to fix multi-jvm failure when untyped system is adapted from typed system in Conductor
* Attempt to fix multi-jvm tests failing due to some ordering issue with systemActorOf
* Update MiMa: drop 2.4, add 2.5
We promise binary compatibility across minor versions, which would in theory
mean we should check compatibility between 2.4 and 2.6.
However, since 2.4 is EOL, we no longer guarantee bincompat with it. In
practice this should not make much of a difference, since only in rare cases
would a change be binary compatible with 2.5 but not with 2.4.
* Don't run 2.11 on travis
To gracefully shutdown Akka HTTP, you need to first unbind the server,
then terminate the connections. Akka HTTP's ServerBinding.terminate
though also unbinds the server first, which I think is a sensible thing
to do and there's no need to change that behavior, and in theory it's ok
because unbind is immutable. However, the result of invoking unbind
twice in most real world use cases will be that an Unbind message will
get sent to the already terminated TCP stage, and that message will be
dead lettered.
This does a best effort at preventing that. While it doesn't prevent it
in all scenarios (the stage could be unbinding while the Unbind message
is being sent), in practice it will prevent it in all reasonable
scenarios, because generally, terminate will only be inovked after the
unbind future has been redeemed, either by directly mapping it, or
through attachment to different coordinated shutdown stages.
