Merge pull request #126 from CzyerChen/main
fix(doc): fix markdown formatting errors
diff --git a/src/components/classic/documentation/failover-transport-reference.md b/src/components/classic/documentation/failover-transport-reference.md
index 6186a7a..28650c9 100644
--- a/src/components/classic/documentation/failover-transport-reference.md
+++ b/src/components/classic/documentation/failover-transport-reference.md
@@ -68,11 +68,11 @@
The Failover transport tracks transactions by default. In-flight transactions are replayed upon re-connection. For simple scenarios this works as expected. However, there is an assumption regarding acknowledged (or consumer) transactions in that the previously received messages will automatically be replayed upon re-connection. This, however, is not always true when there are many connections and consumers, as re-delivery order is not guaranteed as stale outstanding acknowledgements can interfere with newly delivered messages. This can lead to unacknowledged messages.
-`From ActiveMQ Classic 5.3.1**: re-delivery order **_is_** tracked and a transaction will fail to commit if outstanding messages are not redelivered after failover. A `javax.jms.``TransactionRolledBackException` is thrown if the commit fails. In doubt transactions will result in a rollback such that they can be replayed by the application. In doubt transactions occur when failover happens when a commit message is in-flight. It is not possible to know the exact point of failure. Did failure happen because the transaction commit message was not delivered or was the commit reply lost? In either case, it becomes necessary to rollback the transaction so that the application can get an indication of the failure and deal with any potential problem.
+**From ActiveMQ Classic 5.3.1**: re-delivery order **_is_** tracked and a transaction will fail to commit if outstanding messages are not redelivered after failover. A `javax.jms.TransactionRolledBackException` is thrown if the commit fails. In doubt transactions will result in a rollback such that they can be replayed by the application. In doubt transactions occur when failover happens when a commit message is in-flight. It is not possible to know the exact point of failure. Did failure happen because the transaction commit message was not delivered or was the commit reply lost? In either case, it becomes necessary to rollback the transaction so that the application can get an indication of the failure and deal with any potential problem.
##### Broker-side Options for Failover
-`From ActiveMQ Classic 5.4**: the `TransportConnector` has options available so that the broker can update clients automatically with information regarding the presence of new brokers that are available (or are no longer available) for failover.
+**From ActiveMQ Classic 5.4**: the `TransportConnector` has options available so that the broker can update clients automatically with information regarding the presence of new brokers that are available (or are no longer available) for failover.
The options are:
@@ -107,7 +107,7 @@
##### Priority Backup
-`From ActiveMQ Classic 5.6**: if brokers are available in both local and remote networks, it's possible to specify a preference for local brokers over remote brokers using the `priorityBackup` and `priorityURIs` options.
+**From ActiveMQ Classic 5.6**: if brokers are available in both local and remote networks, it's possible to specify a preference for local brokers over remote brokers using the `priorityBackup` and `priorityURIs` options.
Consider the following URL:
```
@@ -125,7 +125,7 @@
##### Configuring Nested URI Options.
-`From ActiveMQ Classic 5.9**: common URI options can be configured by appending them to the query string of the failover URI where each common URI option has the prefix: `nested.`
+**From ActiveMQ Classic 5.9**: common URI options can be configured by appending them to the query string of the failover URI where each common URI option has the prefix: `nested.`
Example - instead of doing this:
```
diff --git a/src/components/classic/documentation/kahadb-master-slave.md b/src/components/classic/documentation/kahadb-master-slave.md
index 6a000c5..db083f4 100644
--- a/src/components/classic/documentation/kahadb-master-slave.md
+++ b/src/components/classic/documentation/kahadb-master-slave.md
@@ -27,7 +27,7 @@
Master Election
---------------
-KahaDB supports a pluggable Master Election algorithm but the only current implementation is one based on [ZooKeeper](http://hadoop.apache.org/zookeeper).
+KahaDB supports a pluggable Master Election algorithm but the only current implementation is one based on [ZooKeeper](https://zookeeper.apache.org/).
ZooKeeper is used to implement the master election algorithm. ZooKeeper is a very fast, replicated, in memory database with features that make it easy to implement cluster control algorithms. It is an Apache project which you can [freely download](http://hadoop.apache.org/zookeeper/releases.html). You must installed and have at least one ZooKeeper server running before setting up a KahaDB Master Slave configuration.
diff --git a/src/components/classic/documentation/networks-of-brokers.md b/src/components/classic/documentation/networks-of-brokers.md
index fb513b4..9c70e76 100644
--- a/src/components/classic/documentation/networks-of-brokers.md
+++ b/src/components/classic/documentation/networks-of-brokers.md
@@ -55,7 +55,7 @@
### Example using multicast discovery
-This example uses multicast [discovery](http://activemq.apache.orgFeatures/discovery)
+This example uses [multicast discovery](discovery#multicast)
```
<?xml version="1.0" encoding="UTF-8"?>
diff --git a/src/components/classic/documentation/shared-file-system-master-slave.md b/src/components/classic/documentation/shared-file-system-master-slave.md
index ca4bed7..c161537 100644
--- a/src/components/classic/documentation/shared-file-system-master-slave.md
+++ b/src/components/classic/documentation/shared-file-system-master-slave.md
@@ -69,7 +69,7 @@
-One of the other other slaves immediately grabs the exclusive lock on the file system to them commences becoming the master, starting all of its transport connectors.
+One of the other slaves immediately grabs the exclusive lock on the file system to them commences becoming the master, starting all of its transport connectors.
Clients loose connection to the stopped master and then the failover transport tries to connect to the available brokers - of which the only one available is the new master.
