Minor doc fixes

src/main/asciidoc/index.adoc

@@ -53,7 +53,7 @@ which is packaged inside the jar.
 
 If you want to override this configuration you can provide a file called `cluster.xml` on your classpath and this
 will be used instead. If you want to embed the `cluster.xml` file in a fat jar, it must be located at the root of the
-fat jar. If it's an external file, the*directory** containing the file must be added to the classpath. For
+fat jar. If it's an external file, the **directory** containing the file must be added to the classpath. For
 example, if you are using the _launcher_ class from Vert.x, the classpath enhancement can be done as follows:
 
 [source]
@@ -142,7 +142,7 @@ inconsistent state. See https://github.com/vert-x3/vertx-hazelcast/issues/24 for
 **IMPORTANT** Make sure Hazelcast is started before and shut down after Vert.x.
 Also, the Hazelcast shutdown hook should be disabled (see xml example, or via system property).
 
-=== Changing timeout for failed nodes
+== Changing timeout for failed nodes
 
 By default a node will be removed from the cluster if Hazelcast didn't receive a heartbeat for 300 seconds. To change
 this value `hazelcast.max.no.heartbeat.seconds` system property such as in:
@@ -159,15 +159,11 @@ http://docs.hazelcast.org/docs/3.6/manual/html-single/index.html#configuring-wit
 with system properties] for the other properties you can configure.
 
 == Using Hazelcast async methods
-Hazelcast's `IMap` and `IAtomicLong` interfaces can be used with async methods returning `ICompletableFuture<V>`,
-a natural fit for Vert.x threading model. Even though these interfaces have been available for a long time, they are not
-provided by the public `HazelcastInstance` API.
-
-The default behavior of the `HazelcastClusterManager` is to use the public API. Supplying the option
-`-Dvertx.hazelcast.async-api=true` on JVM startup, will indicate that the async Hazelcast API methods will be used to
-communicate with the hazelcast cluster. Effectively, this means that when this option is enabled,
-execution of all `Counter` operations and `AsyncMap.get`,`AsyncMap.put` and `AsyncMap.remove` operations will
-occur in the calling thread (the event loop), instead of a worker thread with `vertx.executeBlocking`.
+
+Hazelcast's `IMap` and `IAtomicLong` interfaces can be used with async methods returning `ICompletableFuture<V>`, a natural fit for Vert.x threading model.
+
+Supplying the option `-Dvertx.hazelcast.async-api=true` on JVM startup, will indicate that the async Hazelcast API methods will be used to communicate with the hazelcast cluster.
+Effectively, this means that when this option is enabled, execution of all `Counter` operations and `AsyncMap.get`,`AsyncMap.put` and `AsyncMap.remove` operations will occur in the calling thread (the event loop), instead of a worker thread with `vertx.executeBlocking`.
 
 == Trouble shooting clustering