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

@ -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.