Promote WeaklyUp and enable by default, #22197

This commit is contained in:
Patrik Nordwall 2017-01-24 12:31:32 +01:00
parent d1ba2c1aae
commit 1700cdaebc
14 changed files with 41 additions and 64 deletions

View file

@ -59,13 +59,11 @@ akka {
# cluster singleton handover to complete) and then quarantine the removed node.
quarantine-removed-node-after=30s
# By default, the leader will not move 'Joining' members to 'Up' during a network
# If this is set to "off", the leader will not move 'Joining' members to 'Up' during a network
# split. This feature allows the leader to accept 'Joining' members to be 'WeaklyUp'
# so they become part of the cluster even during a network split. The leader will
# move 'WeaklyUp' members to 'Up' status once convergence has been reached. This
# feature must be off if some members are running Akka 2.3.X.
# WeaklyUp is an EXPERIMENTAL feature.
allow-weakly-up-members = off
# move 'WeaklyUp' members to 'Up' status once convergence has been reached.
allow-weakly-up-members = on
# The roles of this member. List of strings, e.g. roles = ["A", "B"].
# The roles are part of the membership information and can be used by

View file

@ -183,10 +183,6 @@ sealed abstract class MemberStatus
object MemberStatus {
@SerialVersionUID(1L) case object Joining extends MemberStatus
/**
* WeaklyUp is an EXPERIMENTAL feature and is subject to change until
* it has received more real world testing.
*/
@SerialVersionUID(1L) case object WeaklyUp extends MemberStatus
@SerialVersionUID(1L) case object Up extends MemberStatus
@SerialVersionUID(1L) case object Leaving extends MemberStatus
@ -201,8 +197,6 @@ object MemberStatus {
/**
* Java API: retrieve the weaklyUp status singleton.
* WeaklyUp is an EXPERIMENTAL feature and is subject to change until
* it has received more real world testing.
*/
def weaklyUp: MemberStatus = WeaklyUp

View file

@ -19,7 +19,10 @@ final case class ConvergenceMultiNodeConfig(failureDetectorPuppet: Boolean) exte
val fourth = role("fourth")
commonConfig(debugConfig(on = false).
withFallback(ConfigFactory.parseString("akka.cluster.failure-detector.threshold = 4")).
withFallback(ConfigFactory.parseString("""
akka.cluster.failure-detector.threshold = 4
akka.cluster.allow-weakly-up-members = off
""")).
withFallback(MultiNodeClusterSpec.clusterConfig(failureDetectorPuppet)))
}

View file

@ -277,10 +277,10 @@ marked as ``down`` and new incarnation can rejoin the cluster without manual int
As mentioned before, if a node is ``unreachable`` then gossip convergence is not
possible and therefore any ``leader`` actions are also not possible. By enabling
``akka.cluster.allow-weakly-up-members`` it is possible to let new joining nodes be
promoted while convergence is not yet reached. These ``Joining`` nodes will be
promoted as ``WeaklyUp``. Once gossip convergence is reached, the leader will move
``WeaklyUp`` members to ``Up``.
``akka.cluster.allow-weakly-up-members`` (enabled by default) it is possible to
let new joining nodes be promoted while convergence is not yet reached. These
``Joining`` nodes will be promoted as ``WeaklyUp``. Once gossip convergence is
reached, the leader will move ``WeaklyUp`` members to ``Up``.
Note that members on the other side of a network partition have no knowledge about
the existence of the new members. You should for example not count ``WeaklyUp``

View file

@ -30,7 +30,7 @@ and add the following configuration stanza to your ``application.conf``
akka.extensions = [ "akka.cluster.metrics.ClusterMetricsExtension" ]
Cluster members with status :ref:`WeaklyUp <weakly_up_java>`, if that feature is enabled,
Cluster members with status :ref:`WeaklyUp <weakly_up_java>`,
will participate in Cluster Metrics collection and dissemination.
Metrics Collector

View file

@ -53,8 +53,7 @@ It's worth noting that messages can always be lost because of the distributed na
As always, additional logic should be implemented in the singleton (acknowledgement) and in the
client (retry) actors to ensure at-least-once message delivery.
The singleton instance will not run on members with status :ref:`WeaklyUp <weakly_up_java>` if that feature
is enabled.
The singleton instance will not run on members with status :ref:`WeaklyUp <weakly_up_java>`.
Potential problems to be aware of
---------------------------------

View file

@ -206,32 +206,19 @@ If a node is ``unreachable`` then gossip convergence is not possible and therefo
``leader`` actions are also not possible. However, we still might want new nodes to join
the cluster in this scenario.
.. warning::
The WeaklyUp feature is marked as **“experimental”** as of its introduction in Akka 2.4.0. We will continue to
improve this feature based on our users feedback, which implies that while we try to keep incompatible
changes to a minimum the binary compatibility guarantee for maintenance releases does not apply this feature.
This feature is disabled by default. With a configuration option you can allow this behavior::
akka.cluster.allow-weakly-up-members = on
When ``allow-weakly-up-members`` is enabled and there is no gossip convergence,
``Joining`` members will be promoted to ``WeaklyUp`` and they will become part of the
cluster. Once gossip convergence is reached, the leader will move ``WeaklyUp``
``Joining`` members will be promoted to ``WeaklyUp`` and become part of the cluster if
convergence can't be reached. Once gossip convergence is reached, the leader will move ``WeaklyUp``
members to ``Up``.
This feature is enabled by default, but it can be disabled with configuration option::
akka.cluster.allow-weakly-up-members = off
You can subscribe to the ``WeaklyUp`` membership event to make use of the members that are
in this state, but you should be aware of that members on the other side of a network partition
have no knowledge about the existence of the new members. You should for example not count
``WeaklyUp`` members in quorum decisions.
.. warning::
This feature is only available from Akka 2.4.0 and cannot be used if some of your
cluster members are running an older version of Akka.
.. _cluster_subscriber_java:
Subscribe to Cluster Events
@ -500,8 +487,7 @@ automatically unregistered from the router. When new nodes join the cluster addi
routees are added to the router, according to the configuration. Routees are also added
when a node becomes reachable again, after having been unreachable.
Cluster aware routers make use of members with status :ref:`WeaklyUp <weakly_up_java>` if that feature
is enabled.
Cluster aware routers make use of members with status :ref:`WeaklyUp <weakly_up_java>`.
There are two distinct types of routers.

View file

@ -40,7 +40,7 @@ with a specific role. It communicates with other ``Replicator`` instances with t
(without address) that are running on other nodes . For convenience it can be used with the
``akka.cluster.ddata.DistributedData`` extension.
Cluster members with status :ref:`WeaklyUp <weakly_up_java>`, if that feature is enabled,
Cluster members with status :ref:`WeaklyUp <weakly_up_java>`,
will participate in Distributed Data. This means that the data will be replicated to the
:ref:`WeaklyUp <weakly_up_java>` nodes with the background gossip protocol. Note that it
will not participate in any actions where the consistency mode is to read/write from all

View file

@ -22,7 +22,7 @@ a few seconds. Changes are only performed in the own part of the registry and th
changes are versioned. Deltas are disseminated in a scalable way to other nodes with
a gossip protocol.
Cluster members with status :ref:`WeaklyUp <weakly_up_java>`, if that feature is enabled,
Cluster members with status :ref:`WeaklyUp <weakly_up_java>`,
will participate in Distributed Publish Subscribe, i.e. subscribers on nodes with
``WeaklyUp`` status will receive published messages if the publisher and subscriber are on
same side of a network partition.

View file

@ -314,6 +314,16 @@ used in the test::
akka.coordinated-shutdown.run-by-jvm-shutdown-hook = off
akka.cluster.run-coordinated-shutdown-when-down = off
WeaklyUp
--------
:ref:`weakly_up_scala` is now enabled by default, but it can be disabled with configuration option::
akka.cluster.allow-weakly-up-members = off
You should not run a cluster with this feature enabled on some nodes and disabled on some. Therefore
you might need to enable/disable it in configuration when performing rolling upgrade from 2.4.x to 2.5.0.
Cluster Management Command Line Tool
------------------------------------

View file

@ -53,8 +53,7 @@ It's worth noting that messages can always be lost because of the distributed na
As always, additional logic should be implemented in the singleton (acknowledgement) and in the
client (retry) actors to ensure at-least-once message delivery.
The singleton instance will not run on members with status :ref:`WeaklyUp <weakly_up_scala>` if that feature
is enabled.
The singleton instance will not run on members with status :ref:`WeaklyUp <weakly_up_scala>`.
Potential problems to be aware of
---------------------------------

View file

@ -202,31 +202,19 @@ If a node is ``unreachable`` then gossip convergence is not possible and therefo
``leader`` actions are also not possible. However, we still might want new nodes to join
the cluster in this scenario.
.. warning::
The WeaklyUp feature is marked as **“experimental”** as of its introduction in Akka 2.4.0. We will continue to
improve this feature based on our users feedback, which implies that while we try to keep incompatible
changes to a minimum the binary compatibility guarantee for maintenance releases does not apply this feature.
This feature is disabled by default. With a configuration option you can allow this behavior::
akka.cluster.allow-weakly-up-members = on
When ``allow-weakly-up-members`` is enabled and there is no gossip convergence,
``Joining`` members will be promoted to ``WeaklyUp`` and they will become part of the
cluster. Once gossip convergence is reached, the leader will move ``WeaklyUp``
``Joining`` members will be promoted to ``WeaklyUp`` and become part of the cluster if
convergence can't be reached. Once gossip convergence is reached, the leader will move ``WeaklyUp``
members to ``Up``.
This feature is enabled by default, but it can be disabled with configuration option::
akka.cluster.allow-weakly-up-members = off
You can subscribe to the ``WeaklyUp`` membership event to make use of the members that are
in this state, but you should be aware of that members on the other side of a network partition
have no knowledge about the existence of the new members. You should for example not count
``WeaklyUp`` members in quorum decisions.
.. warning::
This feature is only available from Akka 2.4.0 and cannot be used if some of your
cluster members are running an older version of Akka.
.. _cluster_subscriber_scala:

View file

@ -40,7 +40,7 @@ with a specific role. It communicates with other ``Replicator`` instances with t
(without address) that are running on other nodes . For convenience it can be used with the
``akka.cluster.ddata.DistributedData`` extension.
Cluster members with status :ref:`WeaklyUp <weakly_up_scala>`, if that feature is enabled,
Cluster members with status :ref:`WeaklyUp <weakly_up_scala>`,
will participate in Distributed Data. This means that the data will be replicated to the
:ref:`WeaklyUp <weakly_up_scala>` nodes with the background gossip protocol. Note that it
will not participate in any actions where the consistency mode is to read/write from all

View file

@ -22,7 +22,7 @@ a few seconds. Changes are only performed in the own part of the registry and th
changes are versioned. Deltas are disseminated in a scalable way to other nodes with
a gossip protocol.
Cluster members with status :ref:`WeaklyUp <weakly_up_scala>`, if that feature is enabled,
Cluster members with status :ref:`WeaklyUp <weakly_up_scala>`,
will participate in Distributed Publish Subscribe, i.e. subscribers on nodes with
``WeaklyUp`` status will receive published messages if the publisher and subscriber are on
same side of a network partition.