From a28474ec6f3d4a0f6e527967be8edc7cca98ccdd Mon Sep 17 00:00:00 2001 From: Cassandra Targett Date: Thu, 12 Oct 2017 06:34:54 -0500 Subject: [PATCH] Ref Guide: fix anchor refs that failed the build --- solr/solr-ref-guide/src/solrcloud-autoscaling-overview.adoc | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/solr/solr-ref-guide/src/solrcloud-autoscaling-overview.adoc b/solr/solr-ref-guide/src/solrcloud-autoscaling-overview.adoc index 6d0dcb99704..c14965ada78 100644 --- a/solr/solr-ref-guide/src/solrcloud-autoscaling-overview.adoc +++ b/solr/solr-ref-guide/src/solrcloud-autoscaling-overview.adoc @@ -85,13 +85,13 @@ Now that we have an idea about how cluster management operations use policy and The `autoAddReplicas` parameter passed to the create collection API in the quickstart section automatically creates a trigger that watches for a node going away. When the trigger fires, it computes and executes a plan to move all replicas hosted by the lost node to new nodes in the cluster. The target nodes are chosen based on the policy and preferences. -You can learn more about Triggers in the section <>. +You can learn more about Triggers in the section <>. == Listeners An AutoScaling *Listener* can be attached to a trigger. Solr calls the listener each time the trigger fires as well as before and after the actions performed by the trigger. Listeners are useful as a call back mechanism to perform tasks such as logging or informing external systems about events. For example, a listener is automatically added by Solr to each Trigger to log details of the trigger fire and actions to the `.system` collection. -You can learn more about Listeners in the section <>. +You can learn more about Listeners in the section <>. == Autoscaling APIs