Update links to Lightbend RPv2, more warnings about auto-down

This commit is contained in:
Patrik Nordwall 2016-09-02 10:26:47 +02:00
parent ee116dcdab
commit 0a75f992e4
12 changed files with 72 additions and 39 deletions

View file

@ -26,6 +26,10 @@ akka {
# unreachable nodes as DOWN after a configured time of unreachability?
# Using auto-down implies that two separate clusters will automatically be
# formed in case of network partition.
#
# Don't enable this in production, see 'Auto-downing (DO NOT USE)' section
# of Akka Cluster documentation.
#
# Disable with "off" or specify a duration to enable auto-down.
# If a downing-provider-class is configured this setting is ignored.
auto-down-unreachable-after = off

View file

@ -10,6 +10,7 @@ import scala.concurrent.duration.FiniteDuration
import akka.cluster.ClusterEvent._
import scala.concurrent.duration.Duration
import akka.actor.ActorLogging
/**
* INTERNAL API
@ -51,7 +52,7 @@ final class AutoDowning(system: ActorSystem) extends DowningProvider {
* able to unit test the logic without running cluster.
*/
private[cluster] class AutoDown(autoDownUnreachableAfter: FiniteDuration)
extends AutoDownBase(autoDownUnreachableAfter) {
extends AutoDownBase(autoDownUnreachableAfter) with ActorLogging {
val cluster = Cluster(context.system)
import cluster.InfoLogger._
@ -62,6 +63,8 @@ private[cluster] class AutoDown(autoDownUnreachableAfter: FiniteDuration)
// re-subscribe when restart
override def preStart(): Unit = {
log.warning("Don't use auto-down feature of Akka Cluster in production. " +
"See 'Auto-downing (DO NOT USE)' section of Akka Cluster documentation.")
cluster.subscribe(self, classOf[ClusterDomainEvent])
super.preStart()
}
@ -72,7 +75,9 @@ private[cluster] class AutoDown(autoDownUnreachableAfter: FiniteDuration)
override def down(node: Address): Unit = {
require(leader)
logInfo("Leader is auto-downing unreachable node [{}]", node)
logInfo("Leader is auto-downing unreachable node [{}]. " +
"Don't use auto-down feature of Akka Cluster in production. " +
"See 'Auto-downing (DO NOT USE)' section of Akka Cluster documentation.", node)
cluster.down(node)
}

View file

@ -8,7 +8,7 @@ Akka requires that you have `Java 8 <http://www.oracle.com/technetwork/java/java
later installed on your machine.
`Lightbend Inc. <http://www.lightbend.com>`_ provides a commercial build of Akka and related projects such as Scala or Play
as part of the `Reactive Platform <http://www.lightbend.com/products/lightbend-reactive-platform>`_ which is made available
as part of the `Lightbend Reactive Platform <http://www.lightbend.com/platform>`_ which is made available
for Java 6 in case your project can not upgrade to Java 8 just yet. It also includes additional commercial features or libraries.
Getting Started Guides and Template Projects

View file

@ -25,6 +25,12 @@ to route the message with the entity id to the final destination.
Cluster sharding will not be active on members with status :ref:`WeaklyUp <weakly_up_java>`
if that feature is enabled.
.. warning::
**Don't use Cluster Sharding together with Automatic Downing**,
since it allows the cluster to split up into two separate clusters, which in turn will result
in *multiple shards and entities* being started, one in each separate cluster!
See :ref:`automatic-vs-manual-downing-java`.
An Example
----------
@ -304,6 +310,12 @@ cannot startup because of corrupt data, which may happen if accidentally
two clusters were running at the same time, e.g. caused by using auto-down
and there was a network partition.
.. warning::
**Don't use Cluster Sharding together with Automatic Downing**,
since it allows the cluster to split up into two separate clusters, which in turn will result
in *multiple shards and entities* being started, one in each separate cluster!
See :ref:`automatic-vs-manual-downing-java`.
Use this program as a standalone Java main program::
java -classpath <jar files, including akka-cluster-sharding>

View file

@ -73,7 +73,7 @@ Especially the last point is something you should be aware of — in general whe
you should take care of downing nodes yourself and not rely on the timing based auto-down feature.
.. warning::
**Be very careful when using Cluster Singleton together with Automatic Downing**,
**Don't use Cluster Singleton together with Automatic Downing**,
since it allows the cluster to split up into two separate clusters, which in turn will result
in *multiple Singletons* being started, one in each separate cluster!

View file

@ -126,8 +126,8 @@ be allowed to join.
.. _automatic-vs-manual-downing-java:
Automatic vs. Manual Downing
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Downing
^^^^^^^
When a member is considered by the failure detector to be unreachable the
leader is not allowed to perform its duties, such as changing status of
@ -138,7 +138,17 @@ can be performed automatically or manually. By default it must be done manually,
It can also be performed programmatically with ``Cluster.get(system).down(address)``.
You can enable automatic downing with configuration::
A pre-packaged solution for the downing problem is provided by
`Split Brain Resolver <http://doc.akka.io/docs/akka/akka-commercial-addons-1.0/java/split-brain-resolver.html>`_,
which is part of the `Lightbend Reactive Platform <http://www.lightbend.com/platform>`_.
If you dont use RP, you should anyway carefully read the `documentation <http://doc.akka.io/docs/akka/akka-commercial-addons-1.0/java/split-brain-resolver.html>`_
of the Split Brain Resolver and make sure that the solution you are using handles the concerns
described there.
Auto-downing (DO NOT USE)
-------------------------
There is an atomatic downing feature that you should not use in production. For testing purpose you can enable it with configuration::
akka.cluster.auto-down-unreachable-after = 120s
@ -157,19 +167,8 @@ can also happen because of long GC pauses or system overload.
We recommend against using the auto-down feature of Akka Cluster in production.
This is crucial for correct behavior if you use :ref:`cluster-singleton-java` or
:ref:`cluster_sharding_java`, especially together with Akka :ref:`persistence-java`.
A pre-packaged solution for the downing problem is provided by
`Split Brain Resolver <http://doc.akka.io/docs/akka/rp-16s01p03/java/split-brain-resolver.html>`_,
which is part of the Lightbend Reactive Platform. If you dont use RP, you should anyway carefully
read the `documentation <http://doc.akka.io/docs/akka/rp-16s01p03/java/split-brain-resolver.html>`_
of the Split Brain Resolver and make sure that the solution you are using handles the concerns
described there.
.. note:: If you have *auto-down* enabled and the failure detector triggers, you
can over time end up with a lot of single node clusters if you don't put
measures in place to shut down nodes that have become ``unreachable``. This
follows from the fact that the ``unreachable`` node will likely see the rest of
the cluster as ``unreachable``, become its own leader and form its own cluster.
For Akka Persistence with Cluster Sharding it can result in corrupt data in case
of network partitions.
Leaving
^^^^^^^

View file

@ -588,7 +588,7 @@ it returns false the element is discarded.
**completes** when upstream completes
filterNot
^^^^^^^^
^^^^^^^^^
Filter the incoming elements using a predicate. If the predicate returns false the element is passed downstream, if
it returns true the element is discarded.

View file

@ -25,6 +25,12 @@ to route the message with the entity id to the final destination.
Cluster sharding will not be active on members with status :ref:`WeaklyUp <weakly_up_scala>`
if that feature is enabled.
.. warning::
**Don't use Cluster Sharding together with Automatic Downing**,
since it allows the cluster to split up into two separate clusters, which in turn will result
in *multiple shards and entities* being started, one in each separate cluster!
See :ref:`automatic-vs-manual-downing-java`.
An Example
----------
@ -306,6 +312,12 @@ cannot startup because of corrupt data, which may happen if accidentally
two clusters were running at the same time, e.g. caused by using auto-down
and there was a network partition.
.. warning::
**Don't use Cluster Sharding together with Automatic Downing**,
since it allows the cluster to split up into two separate clusters, which in turn will result
in *multiple shards and entities* being started, one in each separate cluster!
See :ref:`automatic-vs-manual-downing-scala`.
Use this program as a standalone Java main program::
java -classpath <jar files, including akka-cluster-sharding>

View file

@ -73,7 +73,7 @@ Especially the last point is something you should be aware of — in general whe
you should take care of downing nodes yourself and not rely on the timing based auto-down feature.
.. warning::
**Be very careful when using Cluster Singleton together with Automatic Downing**,
**Don't use Cluster Singleton together with Automatic Downing**,
since it allows the cluster to split up into two separate clusters, which in turn will result
in *multiple Singletons* being started, one in each separate cluster!

View file

@ -121,8 +121,8 @@ be allowed to join.
.. _automatic-vs-manual-downing-scala:
Automatic vs. Manual Downing
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Downing
^^^^^^^
When a member is considered by the failure detector to be unreachable the
leader is not allowed to perform its duties, such as changing status of
@ -133,7 +133,17 @@ can be performed automatically or manually. By default it must be done manually,
It can also be performed programmatically with ``Cluster(system).down(address)``.
You can enable automatic downing with configuration::
A pre-packaged solution for the downing problem is provided by
`Split Brain Resolver <http://doc.akka.io/docs/akka/akka-commercial-addons-1.0/scala/split-brain-resolver.html>`_,
which is part of the `Lightbend Reactive Platform <http://www.lightbend.com/platform>`_.
If you dont use RP, you should anyway carefully read the `documentation <http://doc.akka.io/docs/akka/akka-commercial-addons-1.0/scala/split-brain-resolver.html>`_
of the Split Brain Resolver and make sure that the solution you are using handles the concerns
described there.
Auto-downing (DO NOT USE)
-------------------------
There is an atomatic downing feature that you should not use in production. For testing purpose you can enable it with configuration::
akka.cluster.auto-down-unreachable-after = 120s
@ -152,19 +162,9 @@ can also happen because of long GC pauses or system overload.
We recommend against using the auto-down feature of Akka Cluster in production.
This is crucial for correct behavior if you use :ref:`cluster-singleton-scala` or
:ref:`cluster_sharding_scala`, especially together with Akka :ref:`persistence-scala`.
For Akka Persistence with Cluster Sharding it can result in corrupt data in case
of network partitions.
A pre-packaged solution for the downing problem is provided by
`Split Brain Resolver <http://doc.akka.io/docs/akka/rp-16s01p03/scala/split-brain-resolver.html>`_,
which is part of the Lightbend Reactive Platform. If you dont use RP, you should anyway carefully
read the `documentation <http://doc.akka.io/docs/akka/rp-16s01p03/scala/split-brain-resolver.html>`_
of the Split Brain Resolver and make sure that the solution you are using handles the concerns
described there.
.. note:: If you have *auto-down* enabled and the failure detector triggers, you
can over time end up with a lot of single node clusters if you don't put
measures in place to shut down nodes that have become ``unreachable``. This
follows from the fact that the ``unreachable`` node will likely see the rest of
the cluster as ``unreachable``, become its own leader and form its own cluster.
Leaving
^^^^^^^

View file

@ -70,6 +70,7 @@ of programmatically provided parameter.
.. _ForkJoinPool documentation: https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/ForkJoinPool.html
.. _ThreadPoolExecutor documentation: https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/ThreadPoolExecutor.html
Types of dispatchers
--------------------

View file

@ -36,7 +36,7 @@ Building Advanced Directives
----------------------------
This example will showcase the advanced logging using the ``DebuggingDirectives``.
The built `logResponseTime ` directive will log the request time (or rejection reason):
The built `logResponseTime` directive will log the request time (or rejection reason):
.. includecode2:: ../../../../code/docs/http/scaladsl/server/directives/DebuggingDirectivesExamplesSpec.scala
:snippet: logRequestResultWithResponseTime