* Use apidoc directive in typed/cluster.md (#22904) * fix apidoc link Co-authored-by: Arnout Engelen <arnout@engelen.eu> Co-authored-by: Arnout Engelen <arnout@engelen.eu>
This commit is contained in:
Andrei Arlou
GitHub
parent
5dc6755ad2
commit
f16051c064
1 changed files with 18 additions and 18 deletions
|
|
@ -42,11 +42,11 @@ The Cluster extension gives you access to management tasks such as @ref:[Joining
|
|||
and subscription of cluster membership events such as @ref:[MemberUp, MemberRemoved and UnreachableMember](cluster-membership.md#membership-lifecycle),
|
||||
which are exposed as event APIs.
|
||||
|
||||
It does this through these references on the `Cluster` extension:
|
||||
It does this through these references on the @apidoc[typed.Cluster$] extension:
|
||||
|
||||
* `manager`: An @scala[`ActorRef[akka.cluster.typed.ClusterCommand]`]@java[`ActorRef<akka.cluster.typed.ClusterCommand>`] where a `ClusterCommand` is a command such as: `Join`, `Leave` and `Down`
|
||||
* `subscriptions`: An @scala[`ActorRef[akka.cluster.typed.ClusterStateSubscription]`]@java[`ActorRef<akka.cluster.typed.ClusterStateSubscription>`] where a `ClusterStateSubscription` is one of `GetCurrentState` or `Subscribe` and `Unsubscribe` to cluster events like `MemberRemoved`
|
||||
* `state`: The current `CurrentClusterState`
|
||||
* `manager`: An @scala[@apidoc[typed.ActorRef]\[@apidoc[akka.cluster.typed.ClusterCommand](typed.ClusterCommand)\]]@java[@apidoc[typed.ActorRef]<@apidoc[akka.cluster.typed.ClusterCommand](typed.ClusterCommand)>] where a `ClusterCommand` is a command such as: @apidoc[Join], @apidoc[Leave] and @apidoc[Down]
|
||||
* `subscriptions`: An @scala[@apidoc[typed.ActorRef]\[@apidoc[akka.cluster.typed.ClusterStateSubscription](typed.ClusterStateSubscription)\]]@java[@apidoc[typed.ActorRef]<@apidoc[akka.cluster.typed.ClusterStateSubscription](typed.ClusterStateSubscription)>] where a `ClusterStateSubscription` is one of @apidoc[GetCurrentState] or @apidoc[Subscribe] and @apidoc[Unsubscribe] to cluster events like @apidoc[MemberRemoved](ClusterEvent.MemberRemoved)
|
||||
* `state`: The current @apidoc[CurrentClusterState](ClusterEvent.CurrentClusterState)
|
||||
|
||||
All of the examples below assume the following imports:
|
||||
|
||||
|
|
@ -61,7 +61,7 @@ The minimum configuration required is to set a host/port for remoting and the `a
|
|||
|
||||
@@snip [BasicClusterExampleSpec.scala](/akka-cluster-typed/src/test/scala/docs/akka/cluster/typed/BasicClusterExampleSpec.scala) { #config-seeds }
|
||||
|
||||
Accessing the `Cluster` extension on each node:
|
||||
Accessing the @apidoc[typed.Cluster$] extension on each node:
|
||||
|
||||
Scala
|
||||
: @@snip [BasicClusterExampleSpec.scala](/akka-cluster-typed/src/test/scala/docs/akka/cluster/typed/BasicClusterExampleSpec.scala) { #cluster-create }
|
||||
|
|
@ -71,13 +71,13 @@ Java
|
|||
|
||||
@@@ note
|
||||
|
||||
The name of the cluster's `ActorSystem` must be the same for all members, which is passed in when you start the `ActorSystem`.
|
||||
The name of the cluster's @apidoc[typed.ActorSystem] must be the same for all members, which is passed in when you start the `ActorSystem`.
|
||||
|
||||
@@@
|
||||
|
||||
### Joining and Leaving a Cluster
|
||||
|
||||
If not using configuration to specify @ref:[seed nodes to join](#joining), joining the cluster can be done programmatically via the `manager`.
|
||||
If not using configuration to specify @ref:[seed nodes to join](#joining), joining the cluster can be done programmatically via the @scala[@scaladoc[manager](akka.cluster.typed.Cluster#manager:akka.actor.typed.ActorRef[akka.cluster.typed.ClusterCommand])]@java[@javadoc[manager()](akka.cluster.typed.Cluster#manager())].
|
||||
|
||||
Scala
|
||||
: @@snip [BasicClusterExampleSpec.scala](/akka-cluster-typed/src/test/scala/docs/akka/cluster/typed/BasicClusterExampleSpec.scala) { #cluster-join }
|
||||
|
|
@ -95,8 +95,8 @@ Java
|
|||
|
||||
### Cluster Subscriptions
|
||||
|
||||
Cluster `subscriptions` can be used to receive messages when cluster state changes. For example, registering
|
||||
for all `MemberEvent`s, then using the `manager` to have a node leave the cluster will result in events
|
||||
Cluster @scala[@scaladoc[subscriptions](akka.cluster.typed.Cluster#subscriptions:akka.actor.typed.ActorRef[akka.cluster.typed.ClusterStateSubscription])]@java[@javadoc[subscriptions()](akka.cluster.typed.Cluster#subscriptions())] can be used to receive messages when cluster state changes. For example, registering
|
||||
for all @apidoc[MemberEvent](ClusterEvent.MemberEvent)'s, then using the `manager` to have a node leave the cluster will result in events
|
||||
for the node going through the @ref:[Membership Lifecycle](cluster-membership.md#membership-lifecycle).
|
||||
|
||||
This example subscribes to a @scala[`subscriber: ActorRef[MemberEvent]`]@java[`ActorRef<MemberEvent> subscriber`]:
|
||||
|
|
@ -119,12 +119,12 @@ Java
|
|||
### Cluster State
|
||||
|
||||
Instead of subscribing to cluster events it can sometimes be convenient to only get the full membership state with
|
||||
@scala[`Cluster(system).state`]@java[`Cluster.get(system).state()`]. Note that this state is not necessarily in sync with the events published to a
|
||||
@scala[@scaladoc[Cluster(system).state](akka.cluster.typed.Cluster#state:akka.cluster.ClusterEvent.CurrentClusterState)]@java[@javadoc[Cluster.get(system).state()](akka.cluster.typed.Cluster#state())]. Note that this state is not necessarily in sync with the events published to a
|
||||
cluster subscription.
|
||||
|
||||
See @ref:[Cluster Membership](cluster-membership.md#member-events) more information on member events specifically.
|
||||
There are more types of change events, consult the API documentation
|
||||
of classes that extends `akka.cluster.ClusterEvent.ClusterDomainEvent` for details about the events.
|
||||
of classes that extends @apidoc[akka.cluster.ClusterEvent.ClusterDomainEvent](ClusterEvent.ClusterDomainEvent) for details about the events.
|
||||
|
||||
## Cluster Membership API
|
||||
|
||||
|
|
@ -249,7 +249,7 @@ and attempts to join, the existing member will be removed and its new incarnatio
|
|||
There are a few ways to remove a member from the cluster.
|
||||
|
||||
1. The recommended way to leave a cluster is a graceful exit, informing the cluster that a node shall leave.
|
||||
This is performed by @ref:[Coordinated Shutdown](../coordinated-shutdown.md) when the `ActorSystem`
|
||||
This is performed by @ref:[Coordinated Shutdown](../coordinated-shutdown.md) when the @apidoc[typed.ActorSystem]
|
||||
is terminated and also when a SIGTERM is sent from the environment to stop the JVM process.
|
||||
1. Graceful exit can also be performed using @ref:[HTTP](../additional/operations.md#http) or @ref:[JMX](../additional/operations.md#jmx).
|
||||
1. When a graceful exit is not possible, for example in case of abrupt termination of the the JVM process, the node
|
||||
|
|
@ -297,7 +297,7 @@ are running on a crashed (unreachable) node will not be started on another node
|
|||
been removed from the Cluster. Removal of crashed (unreachable) nodes is performed after a downing decision.
|
||||
|
||||
Downing can also be performed programmatically with @scala[`Cluster(system).manager ! Down(address)`]@java[`Cluster.get(system).manager().tell(Down(address))`],
|
||||
but that is mostly useful from tests and when implementing a `DowningProvider`.
|
||||
but that is mostly useful from tests and when implementing a @apidoc[DowningProvider].
|
||||
|
||||
If a crashed node is restarted and joining the cluster again with the same hostname and port, the previous incarnation
|
||||
of that member will first be downed and removed. The new join attempt with same hostname and port is used as evidence
|
||||
|
|
@ -316,8 +316,8 @@ for example cluster-aware routers, can take node roles into account to achieve t
|
|||
The node roles are defined in the configuration property named `akka.cluster.roles`
|
||||
and typically defined in the start script as a system property or environment variable.
|
||||
|
||||
The roles are part of the membership information in `MemberEvent` that you can subscribe to. The roles
|
||||
of the own node are available from the `selfMember` and that can be used for conditionally starting certain
|
||||
The roles are part of the membership information in @apidoc[MemberEvent](ClusterEvent.MemberEvent) that you can subscribe to. The roles
|
||||
of the own node are available from the @scala[@scaladoc[selfMember](akka.cluster.typed.Cluster#selfMember:akka.cluster.Member)]@java[@javadoc[selfMember()](akka.cluster.typed.Cluster#selfMember())] and that can be used for conditionally starting certain
|
||||
actors:
|
||||
|
||||
Scala
|
||||
|
|
@ -337,8 +337,8 @@ unreachable from the rest of the cluster. Please see:
|
|||
|
||||
### Using the Failure Detector
|
||||
|
||||
Cluster uses the `akka.remote.PhiAccrualFailureDetector` failure detector by default, or you can provide your by
|
||||
implementing the `akka.remote.FailureDetector` and configuring it:
|
||||
Cluster uses the @apidoc[akka.remote.PhiAccrualFailureDetector](PhiAccrualFailureDetector) failure detector by default, or you can provide your by
|
||||
implementing the @apidoc[akka.remote.FailureDetector](FailureDetector) and configuring it:
|
||||
|
||||
```
|
||||
akka.cluster.implementation-class = "com.example.CustomFailureDetector"
|
||||
|
|
@ -414,7 +414,7 @@ Creating a cluster is about deploying two or more nodes and having them behave a
|
|||
|
||||
The Configuration Compatibility Check feature ensures that all nodes in a cluster have a compatible configuration. Whenever a new node is joining an existing cluster, a subset of its configuration settings (only those that are required to be checked) is sent to the nodes in the cluster for verification. Once the configuration is checked on the cluster side, the cluster sends back its own set of required configuration settings. The joining node will then verify if it's compliant with the cluster configuration. The joining node will only proceed if all checks pass, on both sides.
|
||||
|
||||
New custom checkers can be added by extending `akka.cluster.JoinConfigCompatChecker` and including them in the configuration. Each checker must be associated with a unique key:
|
||||
New custom checkers can be added by extending @apidoc[akka.cluster.JoinConfigCompatChecker](JoinConfigCompatChecker) and including them in the configuration. Each checker must be associated with a unique key:
|
||||
|
||||
```
|
||||
akka.cluster.configuration-compatibility-check.checkers {
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue