[skip ci] Spell check

Signed-off-by: Robert Dale <robdale@gmail.com>

CONTRIBUTING.md

@@ -127,7 +127,7 @@ $ git ci
 to commit files, and it will automatically append the `-s` switch to ensure that
 you've signed the contribution.
 
-> Note: as it is an alias, you can still append flags to the commad line, e.g.,
+> Note: as it is an alias, you can still append flags to the command line, e.g.,
 > `git ci -v` will get you a diff of your commit while writing your commit
 > message.
 
@@ -161,7 +161,7 @@ changes.
 
 Go to the [JanusGraph repository](https://github.com/JanusGraph/janusgraph) and
 you should see that it will offer you a chance to compare your recently-pushed
-branch to the current `master` of JanusGraph and subit a PR at the same time.
+branch to the current `master` of JanusGraph and submit a PR at the same time.
 
 Review the [PR check list](.github/PULL_REQUEST_TEMPLATE.md) for criteria for acceptable contributions.
 

UPGRADE.asc

@@ -60,7 +60,7 @@ mgmt.commit()
 ===== Node client
 
 A node client with JanusGraph can be configured in a few ways. If the node
-client was configured as a clienty-only or non-data node, follow the steps
+client was configured as a client-only or non-data node, follow the steps
 from the <<_transport_client, transport client>> section to connect to the
 existing cluster using the `REST_CLIENT` instead. If the node client was
 a data node (local-mode), then convert it into a standalone Elasticsearch

docs/advblueprints.txt

@@ -1,5 +1,5 @@
 [[advanced-blueprints]]
-Advanced Tinkerpop
+Advanced TinkerPop
 -------------------
 
 http://tinkerpop.apache.org/[Tinkerpop] provides a set of common http://tinkerpop.apache.org/docs/$MAVEN{tinkerpop.version}/reference#traversalstrategy[traversal strategies] that add additional functionality to graphs.

docs/basics.txt

@@ -324,7 +324,7 @@ mgmt.commit()
 Note, that schema name changes may not be immediately visible in currently running transactions and other JanusGraph graph instances in the cluster. While schema name changes are announced to all JanusGraph instances through the storage backend, it may take a while for the schema changes to take effect and it may require a instance restart in the event of certain failure conditions - like network partitions - if they coincide with the rename. Hence, the user must ensure that either of the following holds:
 
 * The renamed label or key is not currently in active use (i.e. written or read) and will not be in use until all JanusGraph instances are aware of the name change.
-* Running transactions actively accomodate the brief intermediate period where either the old or new name is valid based on the specific JanusGraph instance and status of the name-change announcement. For instance, that could mean transactions query for both names simultaneously.
+* Running transactions actively accommodate the brief intermediate period where either the old or new name is valid based on the specific JanusGraph instance and status of the name-change announcement. For instance, that could mean transactions query for both names simultaneously.
 
 Should the need arise to re-define an existing schema type, it is recommended to change the name of this type to a name that is not currently (and will never be) in use. After that, a new label or key can be defined with the original name, thereby effectively replacing the old one.
 However, note that this would not affect vertices, edges, or properties previously written with the existing type. Redefining existing graph elements is not supported online and must be accomplished through a batch graph transformation.
@@ -556,7 +556,7 @@ cp conf/gremlin-server/gremlin-server.yaml conf/gremlin-server/socket-gremlin-se
 ```
 +
 . Edit the socket-gremlin-server.yaml file and make the following updates:
-.. If you are planning to connect to JanusGraph Server from something other than localhost, update the ip address for host:
+.. If you are planning to connect to JanusGraph Server from something other than localhost, update the IP address for host:
 +
 ```
 host: 10.10.10.100
@@ -604,7 +604,7 @@ cp conf/gremlin-server/gremlin-server.yaml conf/gremlin-server/http-gremlin-serv
 ```
 +
 . Edit the http-gremlin-server.yaml file and make the following updates:
-.. If you are planning to connect to JanusGraph Server from something other than localhost, update the ip address for host:
+.. If you are planning to connect to JanusGraph Server from something other than localhost, update the IP address for host:
 +
 ```
 host: 10.10.10.100
@@ -891,7 +891,7 @@ mgmt.commit()
 
 The example above defines a mixed index containing the property keys `name` and `age`. The definition refers to the indexing backend name `search` so that JanusGraph knows which configured indexing backend it should use for this particular index.  The `search` parameter specified in the buildMixedIndex call must match the second clause in the JanusGraph configuration definition like this: index.*search*.backend   If the index was named 'solrsearch' then the configuration definition would appear like this: index.*solrsearch*.backend.
 
-The mgmt.buildIndex example specified above uses text search as its default behavior. An index statement that explicity defines the index as a text index can be written as follows:
+The mgmt.buildIndex example specified above uses text search as its default behavior. An index statement that explicitly defines the index as a text index can be written as follows:
 
 [source,gremlin]
 mgmt.buildIndex('nameAndAge',Vertex.class).addKey(name,Mapping.TEXT.getParameter()).addKey(age,Mapping.TEXT.getParameter()).buildMixedIndex("search")
@@ -1073,7 +1073,7 @@ Ordered vertex queries are a JanusGraph extension to Gremlin which causes the ve
 
 Almost all interaction with JanusGraph is associated with a transaction.  JanusGraph transactions are safe for concurrent use by multiple threads.  Methods on a JanusGraph instance like `graph.V(...)` and `graph.tx().commit()` perform a `ThreadLocal` lookup to retrieve or create a transaction associated with the calling thread.  Callers can alternatively forego `ThreadLocal` transaction management in favor of calling `graph.tx().createThreadedTx()`, which returns a reference to a transaction object with methods to read/write graph data and commit or rollback.
 
-JanusGraph transactions are not necessarily ACID.  They can be so configured on BerkleyDB, but they are not generally so on Cassandra or HBase, where the underlying storage system does not provide serializable isolation or multi-row atomic writes and the cost of simulating those properties would be substantial.
+JanusGraph transactions are not necessarily ACID.  They can be so configured on BerkeleyDB, but they are not generally so on Cassandra or HBase, where the underlying storage system does not provide serializable isolation or multi-row atomic writes and the cost of simulating those properties would be substantial.
 
 This section describes JanusGraph's transactional semantics and API.
 

docs/bulkloading.txt

@@ -72,7 +72,7 @@ During bulk loading, the load on the cluster typically increases making it more
 
 //==== BatchGraph
 
-//For medium size graph datasets (up to 100s million edges), Tinkerpop ' http://tinkerpop.apache.org/docs/$MAVEN{tinkerpop.version}/#_batchgraph[BatchGraph] is a useful tool for bulk loading data into JanusGraph from a single machine through JanusGraph's native Blueprints interface. BatchGraph effectively caches externally provided vertex ids to eliminate reads against JanusGraph. This allows bulk loading with minimal read load.
+//For medium size graph datasets (up to 100s million edges), TinkerPop ' http://tinkerpop.apache.org/docs/$MAVEN{tinkerpop.version}/#_batchgraph[BatchGraph] is a useful tool for bulk loading data into JanusGraph from a single machine through JanusGraph's native Blueprints interface. BatchGraph effectively caches externally provided vertex ids to eliminate reads against JanusGraph. This allows bulk loading with minimal read load.
 
 //BatchGraph is limited to single machine bulk loading use cases and requires enough local RAM to hold the entire vertex id cache in memory. BatchGraph supports id compression to reduce the memory requirements. Please refer to the https://github.com/tinkerpop/blueprints/wiki/Batch-Implementation[BatchGraph documentation] for more information on how to use BatchGraph most effectively.
 

docs/configuredgraphfactory.txt

@@ -345,7 +345,7 @@ This is why updates to your configurations require a few steps to guarantee corr
 
 This is a new configuration option you can use when defining a property in your configuration that defines how to access a graph. All configurations that include this property will result in the graph instantiation happening through the `JanusGraphManager` (process explained above).
 
-For backwards compatability, any graphs that do not supply this parameter but supplied at server start in your graphs object in your .yaml file, these graphs will be bound through the JanusGraphManager denoted by their `key` supplied for that graph. For example, if your .yaml graphs object looks like:
+For backwards compatibility, any graphs that do not supply this parameter but supplied at server start in your graphs object in your .yaml file, these graphs will be bound through the JanusGraphManager denoted by their `key` supplied for that graph. For example, if your .yaml graphs object looks like:
 
 [source, properties]
 ----

docs/directindex.txt

@@ -43,7 +43,7 @@ In addition <<elasticsearch, Elasticsearch>> supports wildcard queries, use "v.\
 
 === Query Totals
 
-It is sometimes useful to know how many total results were returned from a query without having to retrieve all results.  Fortunately, Elasticsearch and Solr provide a shortcut that does not involve retreiving and ranking all documents.  This shortcut is exposed through the ".vertexTotals()", ".edgeTotals()", and ".propertyTotals()" methods.
+It is sometimes useful to know how many total results were returned from a query without having to retrieve all results.  Fortunately, Elasticsearch and Solr provide a shortcut that does not involve retrieving and ranking all documents.  This shortcut is exposed through the ".vertexTotals()", ".edgeTotals()", and ".propertyTotals()" methods.
 
 The totals can be retrieved using the same query syntax as the indexQuery builder, but size is overwritten to be 0.
 

docs/elasticsearch.txt

@@ -86,7 +86,7 @@ The REST client accepts the `index.[X].bulk-refresh` option. This option control
 
 ==== Ingest Pipelines
 If using Elasticsearch 5.0 or higher, a different ingest pipelines can be set for each mixed index.
-Ingest pipeleine can be use to pre-process documents before indexing. A pipeline is composed by a series of processors. Each processor transforms the document in some way.
+Ingest pipeline can be use to pre-process documents before indexing. A pipeline is composed by a series of processors. Each processor transforms the document in some way.
 For example https://www.elastic.co/guide/en/elasticsearch/reference/current/date-processor.html[date processor] can extract a date from a text to a date field. So you can query this date with JanusGraph without it being physically in the primary storage.
 
 * `index.[X].elasticsearch.ingest-pipeline.[mixedIndexName] = pipeline_id`

docs/hbase.txt

@@ -167,7 +167,7 @@ hadoop fs -ls /
 
 === Tips and Tricks for Managing an HBase Cluster
 
-The http://wiki.apache.org/hadoop/Hbase/Shell[HBase shell] on the master server can be used to get an overal status check of the cluster.
+The http://wiki.apache.org/hadoop/Hbase/Shell[HBase shell] on the master server can be used to get an overall status check of the cluster.
 
 [source, bourne]
 $HBASE_HOME/bin/hbase shell

docs/monitoring.txt

@@ -5,7 +5,7 @@
 
 JanusGraph supports http://dropwizard.io/[Metrics].  JanusGraph can measure the following:
 
-* The number of transactions begun, comitted, and rolled back
+* The number of transactions begun, committed, and rolled back
 * The number of attempts and failures of each storage backend operation type
 * The response time distribution of each storage backend operation type
 
@@ -34,7 +34,7 @@ metrics.prefix = janusgraph
 Transaction-Specific Metrics Names
 +++++++++++++++++++++++++++++++++
 
-Each JanusGraph transaction may optionally specify its own Metrics name prefix, overridding both the default Metrics name prefix and the `metrics.prefix` configuration property.  For example, the prefix could be changed to the name of the frontend application that opened the JanusGraph transaction.  Note that Metrics maintains a ConcurrentHashMap of metric names and their associated objects in memory, so it's probably a good idea to keep the number of distinct metric prefixes small.
+Each JanusGraph transaction may optionally specify its own Metrics name prefix, overriding both the default Metrics name prefix and the `metrics.prefix` configuration property.  For example, the prefix could be changed to the name of the frontend application that opened the JanusGraph transaction.  Note that Metrics maintains a ConcurrentHashMap of metric names and their associated objects in memory, so it's probably a good idea to keep the number of distinct metric prefixes small.
 
 To do this, call `TransactionBuilder.setMetricsPrefix(String)`: