This closes #2352

docs/migration-guide/en/README.md

@@ -29,7 +29,7 @@ This is one of the main differences between ActiveMQ 5.x and Artemis. It's impor
 
 ## Addressing differences
 
-Another big difference that's good to cover early on is the difference is how message addressing and routing is done. ActiveMQ started as a open source JMS implementation, so at its core all JMS concepts like queues, topics and durable subscriptions are implemented as the first-class citizens. It's all based on OpenWire protocol developed within the project and even KahaDB message store is OpenWire centric. This means that all other supported protocols, like MQTT and AMQP are translated internally into OpenWire.
+Another big difference that's good to cover early on is the difference is how message addressing and routing is done. ActiveMQ started as an open source JMS implementation, so at its core all JMS concepts like queues, topics and durable subscriptions are implemented as the first-class citizens. It's all based on OpenWire protocol developed within the project and even KahaDB message store is OpenWire centric. This means that all other supported protocols, like MQTT and AMQP are translated internally into OpenWire.
 
 Artemis took a different approach. It implements only queues internally and all other messaging concepts are achieved by routing messages to appropriate queue(s) using addresses. Messaging concepts like publish-subscribe (topics) and point-to-point (queues) are implemented using different type of routing mechanisms on addresses. *Multicast* routing is used to implement *publish-subscribe* semantics, where all subscribers to a certain address will get their own internal queue and messages will be routed to all of them. *Anycast* routing is used implement *point-to-point* semantics, where there'll be only one queue for the address and all consumers will subscribe to it. The addressing and routing scheme is used across all protocols. So for example, you can view the JMS topic just as a multicast address. We'll cover this topic in more details in the later articles.
 

docs/migration-guide/en/VirtualTopics.md

@@ -21,7 +21,7 @@ JMS 2.0 adds the possibility of shared subscriptions with new API's that are ful
 Fully Qualified Queue name (FQQN)
 ---------------------------------
 Secondly, Artemis uses a queue per topic subscriber model internally and it is possibly to directly address the
-subscription queue using it's Fully Qualified Queue name (FQQN).
+subscription queue using its Fully Qualified Queue name (FQQN).
 
 For example, a default 5.x consumer destination for topic `VirtualTopic.Orders` subscription `A`:
 ```
@@ -46,7 +46,7 @@ the virtual topic consumer destination and an int that specifies the number of p
 queue identity.
 
 E.g: For the default 5.x virtual topic consumer prefix of ```Consumer.*.``` the parameter ```virtualTopicConsumerWildcards``` should be: ```Consumer.*.>;2```.
-However, there is a caveat because this value needs to be a encoded in a uri for the xml configuration. Any unsafe url characters
+However, there is a caveat because this value needs to be encoded in a uri for the xml configuration. Any unsafe url characters
 , in this case: ```> ;``` need to be escaped with their hex code point representation; leading to a value of ```Consumer.*.%3E%3B2```. 
 In this way a consumer destination of ```Consumer.A.VirtualTopic.Orders``` will be transformed into a FQQN of
 ```VirtualTopic.Orders::Consumer.A```. 

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

@@ -488,7 +488,7 @@ If a user requires to pre-create a queue that behaves like a non-durable
 subscription queue the **purge-on-no-consumers** flag can be enabled on the
 queue.  When **purge-on-no-consumers** is set to **true**.  The queue will not
 start receiving messages until a consumer is attached.  When the last consumer
-is detached from the queue.  The queue is purged (it's messages are removed)
+is detached from the queue.  The queue is purged (its messages are removed)
 and will not receive any more messages until a new consumer is attached.
 
 Open the file `<broker-instance>/etc/broker.xml` for editing.

docs/user-manual/en/config-reload.md

@@ -78,7 +78,7 @@ defined.
 > security-sensitive operation.
 
 Below lists the effects of adding, deleting and updating of an
-element/attribute within the `<security-settings>` element, whether an change
+element/attribute within the `<security-settings>` element, whether a change
 can be done or can’t be done.
 
 Operation | Add | Delete | Update
@@ -114,7 +114,7 @@ broker. It contains a list of `<address-setting>` elements.
    > `config-delete-queues` as described in the doc.
 
 Below lists the effects of adding, deleting and updating of an
-element/attribute within the address-settings element, whether an change can be
+element/attribute within the address-settings element, whether a change can be
 done or can’t be done.
 
 Operation | Add | Delete | Update
@@ -166,7 +166,7 @@ and several sub-elements that defines the properties of a divert.
 > this happen you need a restart of the broker.
 
 Below lists the effects of adding, deleting and updating of an
-element/attribute within the diverts element, whether an change can be done or
+element/attribute within the diverts element, whether a change can be done or
 can’t be done.
 
 Operation | Add | Delete | Update
@@ -201,7 +201,7 @@ all `<address>` elements in `<addresses>` will be reloaded.
 > `config-delete-queues` as described in this doc.
 
 Below lists the effects of adding, deleting and updating of an
-element/attribute within the `<addresses>` element, whether an change can be
+element/attribute within the `<addresses>` element, whether a change can be
 done or can’t be done.
 
 Operation | Add | Delete | Update
@@ -210,7 +210,7 @@ Operation | Add | Delete | Update
 `<address>` | A new address will be deployed in the running broker | The corresponding address will be undeployed. | N/A
 attribute `name` | N/A | X | After reloading the address of the old name will be undeployed and the new will be deployed.
 `<anycast>` | X(no more than one is present) | The anycast routing type will be undeployed from this address, as well as its containing queues after reloading | N/A
-`<queue>`(under `<anycast>`) | A anycast queue will be deployed after reloading | The anycast queue will be undeployed | For updating queues please see next section `<queues>`
+`<queue>`(under `<anycast>`) | An anycast queue will be deployed after reloading | The anycast queue will be undeployed | For updating queues please see next section `<queues>`
 `<multicast>` | X(no more than one is present) | The multicast routing type will be undeployed from this address, as well as its containing queues after reloading | N/A
 `<queue>`(under `<multicast>`) | A multicast queue will be deployed after reloading | The multicast queue will be undeployed | For updating queues please see next section `<queues>`
 
@@ -232,7 +232,7 @@ The `<queues>` element contains a list `<queue>` elements. Once changed, all
 > `config-delete-queues` as described in this doc.
 
 Below lists the effects of adding, deleting and updating of an
-element/attribute within the `<queues>` element, and whether an change can be
+element/attribute within the `<queues>` element, and whether a change can be
 done or can’t be done.
 
 Operation | Add | Delete | Update

docs/user-manual/en/duplicate-detection.md

@@ -128,7 +128,7 @@ value for this parameter is `true`.
 
 Core bridges can be configured to automatically add a unique duplicate
 id value (if there isn't already one in the message) before forwarding
-the message to it's target. This ensures that if the target server
+the message to its target. This ensures that if the target server
 crashes or the connection is interrupted and the bridge resends the
 message, then if it has already been received by the target server, it
 will be ignored.

docs/user-manual/en/ha.md

@@ -273,7 +273,7 @@ HA strategy Replication for `slave`:
 
 - `allow-failback`
 
-  Whether a server will automatically stop when a another places a request to take over its place. The use case is when the backup has failed over
+  Whether a server will automatically stop when another places a request to take over its place. The use case is when the backup has failed over
 
 - `initial-replication-sync-timeout`
 
@@ -464,7 +464,7 @@ HA strategy Shared Store for `slave`:
 
 - `allow-failback`
 
-  Whether a server will automatically stop when a another places a request to take over its place. The use case is when the backup has failed over.
+  Whether a server will automatically stop when another places a request to take over its place. The use case is when the backup has failed over.
 
 #### Colocated Backup Servers
 

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

@@ -128,7 +128,7 @@ passed to its constructor.
 
   - `ONCE_AND_ONLY_ONCE`
 
-  See Quality Of Service section for a explanation of these modes.
+  See Quality Of Service section for an explanation of these modes.
 
 - Max Batch Size
 

docs/user-manual/en/management.md

@@ -386,7 +386,7 @@ controlled via the `set*`, `get*` and `is*`.  The `*` access is the catch all
 for everything other method that isn't specifically matched.
 
 The `default-access` element is basically the catch all for every method call
-that isn't handled via the `role-access` configuration.  This has teh same
+that isn't handled via the `role-access` configuration.  This has the same
 semantics as a `match` element.
 
 > **Note:**

docs/user-manual/en/masking-passwords.md

@@ -183,7 +183,7 @@ codec other than the default one. For example
 Both ra.xml and MDB activation configuration have a `password` property that
 can be masked preferably using `ENC()` syntax.
 
-Alternatively it can use a optional attribute in ra.xml to indicate that a
+Alternatively it can use an optional attribute in ra.xml to indicate that a
 password is masked:
 
 `UseMaskedPassword` -- If setting to "true" the passwords are masked.  Default

docs/user-manual/en/message-expiry.md

@@ -6,7 +6,7 @@ Apache ActiveMQ Artemis will not deliver a message to a consumer after it's
 time to live has been exceeded. If the message hasn't been delivered by the
 time that time to live is reached the server can discard it.
 
-Apache ActiveMQ Artemis's addresses can be assigned a expiry address so that,
+Apache ActiveMQ Artemis's addresses can be assigned an expiry address so that,
 when messages are expired, they are removed from the queue and sent to the
 expiry address. Many different queues can be bound to an expiry address.  These
 *expired* messages can later be consumed for further inspection.

docs/user-manual/en/messaging-concepts.md

@@ -248,7 +248,7 @@ Please see [Stomp](stomp.md) for using STOMP with Apache ActiveMQ Artemis.
 
 ### OpenWire
 
-ActiveMQ 5.x defines it's own wire protocol: OpenWire.  In order to support
+ActiveMQ 5.x defines its own wire protocol: OpenWire.  In order to support
 ActiveMQ 5.x clients, Apache ActiveMQ Artemis supports OpenWire.  Any ActiveMQ
 5.12.x or higher can be used with Apache ActiveMQ Artemis.
 

docs/user-manual/en/mqtt.md

@@ -38,14 +38,14 @@ sent or received:
   Guarantees that a particular message is only ever received by the subscriber
   a maximum of one time. This does mean that the message may never arrive.  The
   sender and the receiver will attempt to deliver the message, but if something
-  fails and the message does not reach it's destination (say due to a network
+  fails and the message does not reach its destination (say due to a network
   connection) the message may be lost. This QoS has the least network traffic
   overhead and the least burden on the client and the broker and is often useful
   for telemetry data where it doesn't matter if some of the data is lost.
 
 - QoS 1: `AT LEAST ONCE`
 
-  Guarantees that a message will reach it's intended recipient one or more
+  Guarantees that a message will reach its intended recipient one or more
   times.  The sender will continue to send the message until it receives an
   acknowledgment from the recipient, confirming it has received the message. The
   result of this QoS is that the recipient may receive the message multiple

docs/user-manual/en/openwire.md

@@ -89,7 +89,7 @@ destination into a FQQN address. This address then represents the consumer as a
 multicast binding to an address representing the virtual topic. 
 
 The configuration string property `virtualTopicConsumerWildcards` has two parts
-seperated by a `;`. The first is the 5.x style destination filter that
+separated by a `;`. The first is the 5.x style destination filter that
 identifies the destination as belonging to a virtual topic. The second
 identifies the number of `paths` that identify the consumer queue such that it
 can be parsed from the destination. For example, the default 5.x virtual topic

docs/user-manual/en/persistence.md

@@ -3,7 +3,7 @@
 Apache ActiveMQ Artemis ships with two persistence options.  The file journal which is 
 highly optimized for the messaging use case and gives great performance, and also the
 JDBC Store, which uses JDBC to connect to a database of your choice.  The JDBC Store is 
-still under development, but it is possible to use it's journal features, (essentially 
+still under development, but it is possible to use its journal features, (essentially
 everything except for paging and large messages).
 
 ## File Journal (Default)
@@ -114,7 +114,7 @@ The standard Apache ActiveMQ Artemis core server uses two instances of the journ
   fall back to using Java NIO which is available on any Java platform.
 
   The files on this journal are prefixed as `activemq-data`. Each file
-  has a `amq` extension. File size is by the default `10485760`
+  has an `amq` extension. File size is by the default `10485760`
   (configurable), and it is located at the journal folder.
 
 For large messages, Apache ActiveMQ Artemis persists them outside the message journal.
@@ -444,7 +444,7 @@ To configure Apache ActiveMQ Artemis to use a database for persisting messages a
   
 - `page-store-table-name`
 
-  The name of the table to house the page store directory information.  Note that each address will have it's own page table which will use this name appended with a unique id of up to 20 characters.
+  The name of the table to house the page store directory information.  Note that each address will have its own page table which will use this name appended with a unique id of up to 20 characters.
 
 - `node-manager-store-table-name`
 

docs/user-manual/en/rest.md

@@ -581,7 +581,7 @@ own `create-next` URL. The `msg-create-with-id` header looks like this
 msg-create-with-id: http://example.com/queues/bar/create/{id}
 ```
 
-You see that it is a regular URL appended with a `{id}`. This `{id}` is
+You see that it is a regular URL appended with an `{id}`. This `{id}` is
 a pattern matching substring. A client would generate its
 `DUPLICATE_DETECTION_ID` and replace `{id}` with that generated id, then
 POST to the new URL. The URL the client creates works exactly like a

docs/user-manual/en/security.md

@@ -920,7 +920,7 @@ The `GSSAPI` SASL mechanism must be enabled  on the AMQP acceptor in
 ```
 
 The GSSAPI mechanism implementation on the server will use a JAAS configuration
-scope named `amqp-sasl-gssapi` to obtain it's Kerberos acceptor credentials. An
+scope named `amqp-sasl-gssapi` to obtain its Kerberos acceptor credentials. An
 alternative configuration scope can be specified on the AMQP acceptor using the
 url parameter: `saslLoginConfigScope=<some other scope>`.