From c39074279a2ffb7ef67ed137ef7616ce6faaa3f4 Mon Sep 17 00:00:00 2001 From: Devin Villegas Date: Wed, 9 Dec 2015 11:32:43 -0600 Subject: [PATCH] Minor spelling corrections for documentation --- docs/connection.rst | 2 +- docs/index.rst | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/docs/connection.rst b/docs/connection.rst index 26bc8b33..1c42f0c2 100644 --- a/docs/connection.rst +++ b/docs/connection.rst @@ -3,7 +3,7 @@ Connection Layer API ==================== -All of the classes reponsible for handling the connection to the Elasticsearch +All of the classes responsible for handling the connection to the Elasticsearch cluster. The default subclasses used can be overriden by passing parameters to the :class:`~elasticsearch.Elasticsearch` class. All of the arguments to the client will be passed on to :class:`~elasticsearch.Transport`, diff --git a/docs/index.rst b/docs/index.rst index 4c20c4ef..f74fb095 100644 --- a/docs/index.rst +++ b/docs/index.rst @@ -121,7 +121,7 @@ If a connection to a node fails due to connection issues (raises will be placed on hold for ``dead_timeout`` seconds and the request will be retried on another node. If a connection fails multiple times in a row the timeout will get progressively larger to avoid hitting a node that's, by all -indication, down. If no live connection is availible, the connection that has +indication, down. If no live connection is available, the connection that has the smallest timeout will be used. By default retries are not triggered by a timeout @@ -211,7 +211,7 @@ could come into play. When using an http load balancer you cannot use the :ref:`sniffing` functionality - the cluster would supply the client with IP addresses to -directly cnnect to the cluster, circumventing the load balancer. Depending on +directly connect to the cluster, circumventing the load balancer. Depending on your configuration this might be something you don't want or break completely. In some environments (notably on Google App Engine) your http requests might be