NO-JIRA: remove duplicate consecutive words

Removes duplicate consecutives words from markdown
documentation files.

docs/migration-guide/en/key-differences.md

@@ -11,7 +11,7 @@ The other important part of every broker is a message store. Most of the ActiveM
 
 Artemis has its own message store. It consists only of the append-only message journal. Because of the differences in how paging is done, there's no need for the message index. We'll talk more about that in a minute. It's important to say at this point that these two stores are not interchangeable, and data migration if needed must be carefully planed.
 
-What do we mean by paging differences? Paging is the process that happens when broker can't hold all incoming messages in its memory. The strategy of how to deal with this situation differs between two brokers. ActiveMQ have *cursors*, which are basically a cache of messages ready to be dispatched to the consumer. It will try to keep all incoming messages in there. When we run out of the the available memory, messages are added to the store, but the caching stops. When the space become available again, the broker will fill the cache again by pulling messages from the store in batches. Because of this, we need to read the journal from time to time during a broker runtime. In order to do that, we need to maintain a journal index, so that messages' position can be tracked inside the journal.
+What do we mean by paging differences? Paging is the process that happens when broker can't hold all incoming messages in its memory. The strategy of how to deal with this situation differs between two brokers. ActiveMQ have *cursors*, which are basically a cache of messages ready to be dispatched to the consumer. It will try to keep all incoming messages in there. When we run out of the available memory, messages are added to the store, but the caching stops. When the space become available again, the broker will fill the cache again by pulling messages from the store in batches. Because of this, we need to read the journal from time to time during a broker runtime. In order to do that, we need to maintain a journal index, so that messages' position can be tracked inside the journal.
 
 In Artemis, things work differently in this regard. The whole message journal is kept in memory and messages are dispatched directly from it. When we run out of memory, messages are paged *on the producer side* (before they hit the broker). Theay are stored in sequential page files in the same order as they arrived. Once the memory is freed, messages are moved from these page files into the journal. With paging working like this, messages are read from the file journal only when the broker starts up, in order to recreate this in-memory version of the journal. In this case, the journal is only read sequentially, meaning that there's no need to keep an index of messages in the journal.
 

docs/user-manual/en/client-reconnection.md

@@ -68,9 +68,9 @@ Client reconnection is configured using the following parameters:
   milliseconds between subsequent reconnection attempts, if the connection to
   the target server has failed. The default value is `2000` milliseconds.
 
-- `retryIntervalMultiplier`. This optional parameter determines determines a
-  multiplier to apply to the time since the last retry to compute the time to
-  the next retry.
+- `retryIntervalMultiplier`. This optional parameter determines a multiplier
+  to apply to the time since the last retry to compute the time to the next
+  retry.
 
   This allows you to implement an *exponential backoff* between retry attempts.
 

docs/user-manual/en/clusters.md

@@ -301,7 +301,7 @@ We'll consider each parameter of the discovery group:
 
 - `local-bind-address`. If you are running with multiple network
   interfaces on the same machine, you may want to specify that the
-  discovery group listens only only a specific interface. To do this
+  discovery group listens only a specific interface. To do this
   you can specify the interface address with this parameter. This
   parameter is optional. This is a UDP specific attribute.
 

docs/user-manual/en/core-bridges.md

@@ -106,9 +106,9 @@ Let's take a look at all the parameters in turn:
   milliseconds between subsequent reconnection attempts, if the connection to
   the target server has failed. The default value is `2000`milliseconds.
 
-- `retry-interval-multiplier`. This optional parameter determines determines a
-  multiplier to apply to the time since the last retry to compute the time to
-  the next retry.
+- `retry-interval-multiplier`. This optional parameter determines a multiplier
+  to apply to the time since the last retry to compute the time to the next
+  retry.
 
   This allows you to implement an *exponential backoff* between retry
   attempts.

docs/user-manual/en/federation-address.md

@@ -254,7 +254,7 @@ to the `downstream` broker to have it create an `upstream` connection back to th
 this is being able to configure everything for federation on one broker in some cases to make it easier, such
 as a hub and spoke topology
 
-All of the same configuration options apply to to `downstream` as does `upstream` with the exception of one
+All of the same configuration options apply to `downstream` as does `upstream` with the exception of one
 extra configuration flag that needs to be set:
 
   The `transport-connector-ref` is an element pointing to a
@@ -317,4 +317,4 @@ Sample Downstream Address Federation setup:
    </federation>
 </federations>
 
-```
+```

docs/user-manual/en/federation-queue.md

@@ -220,7 +220,7 @@ to the `downstream` broker to have it create an `upstream` connection back to th
 this is being able to configure everything for federation on one broker in some cases to make it easier, such
 as a hub and spoke topology.
 
-All of the same configuration options apply to to `downstream` as does `upstream` with the exception of one
+All of the same configuration options apply to `downstream` as does `upstream` with the exception of one
 extra configuration flag that needs to be set:
 
   The `transport-connector-ref` is an element pointing to a
@@ -284,4 +284,4 @@ extra configuration flag that needs to be set:
    </federation>
 </federations>
   
-  ```
+  ```

docs/user-manual/en/flow-control.md

@@ -154,7 +154,7 @@ total number of producers on address * producer window size
 ```
 
 For example, if I have a queue called "myqueue", I could set the
-maximum memory size to 10MiB, and the the server will control the number
+maximum memory size to 10MiB, and the server will control the number
 of credits sent to any producers which are sending any messages to
 myqueue such that the total messages in the queue never exceeds 10MiB.
 
@@ -235,7 +235,7 @@ messages until the clients credits are exhausted. For this reason there is an ad
 settings that specifies an upper bound on an address size in bytes. Once this upper bound is reach Artemis will start
 rejecting AMQP messages. This limit is the max-size-bytes-reject-threshold and is by default set to -1 (or no limit).
 This is additional parameter allows a kind of soft and hard limit, in normal circumstances the broker will utilize the
-max-size-bytes parameter using using flow control to put back pressure on the client, but will protect the broker by
+max-size-bytes parameter using flow control to put back pressure on the client, but will protect the broker by
 rejecting messages once the address size is reached.
 
 ### Rate limited flow control

docs/user-manual/en/ha.md

@@ -478,7 +478,7 @@ HA strategy shared store for `master`:
 
 - `failover-on-shutdown`
 
-  If set to true then when this server is stopped normally the backup will become live assuming failover. If false then the backup server will remain passive. Note that if false you want failover to occur the you can use the the management API as explained at [Management](management.md).
+  If set to true then when this server is stopped normally the backup will become live assuming failover. If false then the backup server will remain passive. Note that if false you want failover to occur the you can use the management API as explained at [Management](management.md).
 
 - `wait-for-activation`
 
@@ -489,7 +489,7 @@ HA strategy Shared Store for `slave`:
 
 - `failover-on-shutdown`
 
-  In the case of a backup that has become live. then when set to true then when this server is stopped normally the backup will become liveassuming failover. If false then the backup server will remain passive. Note that if false you want failover to occur the you can use the the management API as explained at [Management](management.md).
+  In the case of a backup that has become live. then when set to true then when this server is stopped normally the backup will become liveassuming failover. If false then the backup server will remain passive. Note that if false you want failover to occur the you can use the management API as explained at [Management](management.md).
 
 - `allow-failback`
 
@@ -570,7 +570,7 @@ adding them to the `ha-policy` configuration like so:
 #### Configuring Directories
 
 Directories for the Journal, Large messages and Paging will be set
-according to what the HA strategy is. If shared store the the requesting
+according to what the HA strategy is. If shared store the requesting
 server will notify the target server of which directories to use. If
 replication is configured then directories will be inherited from the
 creating server but have the new backups name appended.

docs/user-manual/en/jms-bridge.md

@@ -54,7 +54,7 @@ class and set the appropriate parameters.
 
 ## JMS Bridge Parameters
 
-The main POJO is the `JMSBridge`. It is is configurable by the parameters
+The main POJO is the `JMSBridge`. It is configurable by the parameters
 passed to its constructor.
 
 - Source Connection Factory Factory
@@ -152,7 +152,7 @@ passed to its constructor.
 - Client ID
 
   If the source destination represents a topic, and you want to consume from
-  the topic using a durable subscription then this attribute represents the the
+  the topic using a durable subscription then this attribute represents the
   JMS client ID to use when creating/looking up the durable subscription
 
 - Add MessageID In Header

docs/user-manual/en/last-value-queues.md

@@ -135,7 +135,7 @@ Another common pattern is to have queue "browsers" which send all messages to th
 
 If every consumer on a queue is non destructive then we can obtain some interesting behaviours. In the case of a LVQ then the queue will always contain the most up to date value for every key. 
 
-A queue can be created to enforce all consumers are non-destructive for last value queue. This can be be achieved using the following queue configuration:
+A queue can be created to enforce all consumers are non-destructive for last value queue. This can be achieved using the following queue configuration:
 
 
 ```xml

docs/user-manual/en/management.md

@@ -83,7 +83,7 @@ The `ActiveMQServerControl` interface is the entry point for broker management.
 
 - Transaction heuristic operations
 
-  In case of a server crash, when the server restarts, it it possible that some
+  In case of a server crash, when the server restarts, it possible that some
   transaction requires manual intervention. The `listPreparedTransactions()`
   method lists the transactions which are in the prepared states (the
   transactions are represented as opaque Base64 Strings.) To commit or rollback a

docs/user-manual/en/mqtt.md

@@ -100,7 +100,7 @@ following steps:
    `handler` like so: `handler.CONSOLE.level=TRACE`.
 
 The MQTT specification doesn't dictate the format of the payloads which clients
-publish. As far as the broker is concerned a payload is just just an array of
+publish. As far as the broker is concerned a payload is just an array of
 bytes. However, to facilitate logging the broker will encode the payloads as
 UTF-8 strings and print them up to 256 characters. Payload logging is limited
 to avoid filling the logs with potentially hundreds of megabytes of unhelpful

docs/user-manual/en/perf-tuning.md

@@ -204,7 +204,7 @@ from other providers (e.g. IBM or JRockit)
   introduce pauses and unintentional behaviour), it is recommended that the max
   heap size (`-Xmx`) for the JVM is set at least to 5 x the `global-max-size` of
   the broker.  As an example, in a situation where the broker is under high load
-  and running with a `global-max-size` of 1GB, it is recommended the the max heap
+  and running with a `global-max-size` of 1GB, it is recommended the max heap
   size is set to 5GB.
 
 ## Avoiding Anti-Patterns

docs/user-manual/en/retroactive-addresses.md

@@ -3,7 +3,7 @@
 A "retroactive" address is an address that will preserve messages sent to it
 for queues which will be created on it in the future. This can be useful in,
 for example, publish-subscribe use cases where clients want to receive the
-messages sent to the address *before* they they actually connected and created
+messages sent to the address *before* they actually connected and created
 their multicast "subscription" queue. Typically messages sent to an address
 before a queue was created on it would simply be unavailable to those queues,
 but with a retroactive address a fixed number of messages can be preserved by
@@ -85,4 +85,4 @@ via ring queues. This is because a ring queue whose ring-size is reduced will
 not automatically delete messages from the queue to meet the new ring-size in
 order to avoid unintended message loss. Therefore, administrative action will
 be required in this case to manually reduce the number of messages in the ring
-queue via the management API.
+queue via the management API.

docs/user-manual/en/security.md

@@ -1110,7 +1110,7 @@ channel.
 
 As the name suggests, the `ActiveMQBasicSecurityManager` is _basic_. It is not
 pluggable like the JAAS security manager and it _only_ supports authentication
-via username and password credentials. Furthermore, the the Hawtio-based web
+via username and password credentials. Furthermore, the Hawtio-based web
 console requires JAAS. Therefore you will *still need* to configure a
 `login.config` if you plan on using the web console. However, this security
 manager *may* still may have a couple of advantages depending on your use-case.
@@ -1400,4 +1400,4 @@ parameter and indicate which domain from your `login.config` to use, e.g.:
 ```
 
 Any client connecting to this acceptor will be have security enforced using
-`mySecurityDomain`.
+`mySecurityDomain`.

docs/user-manual/en/stomp.md

@@ -188,7 +188,7 @@ cause spurious disconnects. Instead, the client-to-server value in the
 `heart-beat` will be multiplied by the `heartBeatToConnectionTtlModifier`
 specified on the acceptor. The `heartBeatToConnectionTtlModifier` is a decimal
 value that defaults to `2.0` so for example, if a client sends a `heart-beat`
-header of `1000,0` the the connection TTL will be set to `2000` so that the
+header of `1000,0` the connection TTL will be set to `2000` so that the
 data or ping frames sent every 1000 milliseconds will have a sufficient cushion
 so as not to be considered late and trigger a disconnect. This is also in
 accordance with the STOMP 1.1 and 1.2 specifications which both state, "because
@@ -412,4 +412,4 @@ overriden by the value provided by individual clients using the
 
 Using the [DEBUG logging](#logging) mentioned earlier it is possible to see the
 size of the `MESSAGE` frames dispatched to clients. This can help when trying
-to determine the best `consumer-window-size` setting.
+to determine the best `consumer-window-size` setting.

docs/user-manual/en/using-jms.md

@@ -143,7 +143,7 @@ The `udp` scheme supports 4 properties:
 
 - `localAddress` - If you are running with multiple network
   interfaces on the same machine, you may want to specify that the
-  discovery group listens only only a specific interface. To do this
+  discovery group listens only on a specific interface. To do this
   you can specify the interface address with this parameter.
 
 - `localPort` - If you want to specify a local port to which the

docs/user-manual/en/using-server.md

@@ -336,7 +336,7 @@ to do start running the broker instance is execute:
 ```
 
 Now that the broker is running, you can optionally run some of the included
-examples to verify the the broker is running properly.
+examples to verify the broker is running properly.
 
 To stop the Apache ActiveMQ Artemis instance you will use the same `artemis`
 script, but with the `stop` argument.  Example:

examples/features/federation/federated-address-downstream-upstream/readme.md

@@ -20,7 +20,7 @@ The following is then carried out:
 
 
 
-In other words, we are showing how with Federated Address, ActiveMQ Artemis **replicates**  sent messages to all addresses and subsequently delivered to all all consumers, regardless if the consumer is local or is on a distant broker. Decoupling the location where producers and consumers need to be.
+In other words, we are showing how with Federated Address, ActiveMQ Artemis **replicates**  sent messages to all addresses and subsequently delivered to all consumers, regardless if the consumer is local or is on a distant broker. Decoupling the location where producers and consumers need to be.
 
 The config that defines the federation you can see in the broker.xml for each broker is within the following tags. You will note upstreams are different in each as well as the federation name, which has to be globally unique.
 
@@ -31,4 +31,4 @@ The config that defines the federation you can see in the broker.xml for each br
 ```
 
 
-For more information on ActiveMQ Artemis Federation please see the federation section of the user manual.
+For more information on ActiveMQ Artemis Federation please see the federation section of the user manual.

examples/features/federation/federated-address-downstream/readme.md

@@ -20,7 +20,7 @@ The following is then carried out:
 
 
 
-In other words, we are showing how with Federated Address, ActiveMQ Artemis **replicates**  sent messages to all addresses and subsequently delivered to all all consumers, regardless if the consumer is local or is on a distant broker. Decoupling the location where producers and consumers need to be.
+In other words, we are showing how with Federated Address, ActiveMQ Artemis **replicates**  sent messages to all addresses and subsequently delivered to all consumers, regardless if the consumer is local or is on a distant broker. Decoupling the location where producers and consumers need to be.
 
 The config that defines the federation you can see in the broker.xml for each broker is within the following tags. You will note upstreams are different in each as well as the federation name, which has to be globally unique.
 
@@ -31,4 +31,4 @@ The config that defines the federation you can see in the broker.xml for each br
 ```
 
 
-For more information on ActiveMQ Artemis Federation please see the federation section of the user manual.
+For more information on ActiveMQ Artemis Federation please see the federation section of the user manual.

examples/features/federation/federated-address/readme.md

@@ -20,7 +20,7 @@ The following is then carried out:
 
 
 
-In other words, we are showing how with Federated Address, ActiveMQ Artemis **replicates**  sent messages to all addresses and subsequently delivered to all all consumers, regardless if the consumer is local or is on a distant broker. Decoupling the location where producers and consumers need to be.
+In other words, we are showing how with Federated Address, ActiveMQ Artemis **replicates**  sent messages to all addresses and subsequently delivered to all consumers, regardless if the consumer is local or is on a distant broker. Decoupling the location where producers and consumers need to be.
 
 The config that defines the federation you can see in the broker.xml for each broker is within the following tags. You will note upstreams are different in each as well as the federation name, which has to be globally unique.
 
@@ -31,4 +31,4 @@ The config that defines the federation you can see in the broker.xml for each br
 ```
 
 
-For more information on ActiveMQ Artemis Federation please see the federation section of the user manual.
+For more information on ActiveMQ Artemis Federation please see the federation section of the user manual.

examples/features/standard/delayed-redelivery/readme.md

@@ -14,10 +14,10 @@ By providing a redelivery delay, it can be specified that a delay of, say, 10 se
 
 Redelivery delay is specified in the configuration file [broker.xml](src/main/resources/activemq/server0/broker.xml):
 
-In this example we set the redelivery delay to 5 seconds for the specific example queue. We could set redelivery delay on on multiple queues by specifying a wild-card in the match, e.g. `match="jms.#"` would apply the settings to all JMS queues and topics.
+In this example we set the redelivery delay to 5 seconds for the specific example queue. We could set redelivery delay on multiple queues by specifying a wild-card in the match, e.g. `match="jms.#"` would apply the settings to all JMS queues and topics.
 
 We then consume a message in a transacted session, and rollback, and note that the message is not redelivered until after 5 seconds.
 
     <address-setting match="exampleQueue">
        <redelivery-delay>5000</redelivery-delay>
-    </address-setting>
+    </address-setting>