From 3400c0d76e9a1dd21b64cc563f60d1f83621d3fb Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Ville=20Skytt=C3=A4?= Date: Mon, 8 Oct 2018 23:05:46 +0300 Subject: [PATCH] NO-JIRA Grammar and spelling fixes --- docs/migration-guide/en/README.md | 2 +- docs/migration-guide/en/VirtualTopics.md | 4 ++-- docs/user-manual/en/address-model.md | 2 +- docs/user-manual/en/config-reload.md | 12 ++++++------ docs/user-manual/en/duplicate-detection.md | 2 +- docs/user-manual/en/ha.md | 4 ++-- docs/user-manual/en/jms-bridge.md | 2 +- docs/user-manual/en/management.md | 2 +- docs/user-manual/en/masking-passwords.md | 2 +- docs/user-manual/en/message-expiry.md | 2 +- docs/user-manual/en/messaging-concepts.md | 2 +- docs/user-manual/en/mqtt.md | 4 ++-- docs/user-manual/en/openwire.md | 2 +- docs/user-manual/en/persistence.md | 6 +++--- docs/user-manual/en/rest.md | 2 +- docs/user-manual/en/security.md | 2 +- 16 files changed, 26 insertions(+), 26 deletions(-) diff --git a/docs/migration-guide/en/README.md b/docs/migration-guide/en/README.md index 7b94148855..8a04fd71a2 100644 --- a/docs/migration-guide/en/README.md +++ b/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. diff --git a/docs/migration-guide/en/VirtualTopics.md b/docs/migration-guide/en/VirtualTopics.md index e470a9fe13..6ad183deff 100644 --- a/docs/migration-guide/en/VirtualTopics.md +++ b/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```. diff --git a/docs/user-manual/en/address-model.md b/docs/user-manual/en/address-model.md index 369a6c0c37..b59753f323 100644 --- a/docs/user-manual/en/address-model.md +++ b/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 `/etc/broker.xml` for editing. diff --git a/docs/user-manual/en/config-reload.md b/docs/user-manual/en/config-reload.md index 630a13d6f0..45029e5ef5 100644 --- a/docs/user-manual/en/config-reload.md +++ b/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 `` element, whether an change +element/attribute within the `` 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 `` 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 `
` elements in `` 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 `` element, whether an change can be +element/attribute within the `` element, whether a change can be done or can’t be done. Operation | Add | Delete | Update @@ -210,7 +210,7 @@ Operation | Add | Delete | Update `
` | 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. `` | 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 -``(under ``) | A anycast queue will be deployed after reloading | The anycast queue will be undeployed | For updating queues please see next section `` +``(under ``) | An anycast queue will be deployed after reloading | The anycast queue will be undeployed | For updating queues please see next section `` `` | 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 ``(under ``) | A multicast queue will be deployed after reloading | The multicast queue will be undeployed | For updating queues please see next section `` @@ -232,7 +232,7 @@ The `` element contains a list `` 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 `` element, and whether an change can be +element/attribute within the `` element, and whether a change can be done or can’t be done. Operation | Add | Delete | Update diff --git a/docs/user-manual/en/duplicate-detection.md b/docs/user-manual/en/duplicate-detection.md index b3e9535977..dd67a26821 100644 --- a/docs/user-manual/en/duplicate-detection.md +++ b/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. diff --git a/docs/user-manual/en/ha.md b/docs/user-manual/en/ha.md index e78b1e4bb9..2402226fa3 100644 --- a/docs/user-manual/en/ha.md +++ b/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 diff --git a/docs/user-manual/en/jms-bridge.md b/docs/user-manual/en/jms-bridge.md index 327d37f0e8..99774f3bb9 100644 --- a/docs/user-manual/en/jms-bridge.md +++ b/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 diff --git a/docs/user-manual/en/management.md b/docs/user-manual/en/management.md index 90546a2e71..ab36c497b9 100644 --- a/docs/user-manual/en/management.md +++ b/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:** diff --git a/docs/user-manual/en/masking-passwords.md b/docs/user-manual/en/masking-passwords.md index 7824b11fec..2e63717f54 100644 --- a/docs/user-manual/en/masking-passwords.md +++ b/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 diff --git a/docs/user-manual/en/message-expiry.md b/docs/user-manual/en/message-expiry.md index 68463f591c..5c727b8376 100644 --- a/docs/user-manual/en/message-expiry.md +++ b/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. diff --git a/docs/user-manual/en/messaging-concepts.md b/docs/user-manual/en/messaging-concepts.md index ab829cccdf..0ed6c42d26 100644 --- a/docs/user-manual/en/messaging-concepts.md +++ b/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. diff --git a/docs/user-manual/en/mqtt.md b/docs/user-manual/en/mqtt.md index dfb8da0104..73b1de423f 100644 --- a/docs/user-manual/en/mqtt.md +++ b/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 diff --git a/docs/user-manual/en/openwire.md b/docs/user-manual/en/openwire.md index 31ada924ce..7d24fb8934 100644 --- a/docs/user-manual/en/openwire.md +++ b/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 diff --git a/docs/user-manual/en/persistence.md b/docs/user-manual/en/persistence.md index b0b253bd5f..df21989e27 100644 --- a/docs/user-manual/en/persistence.md +++ b/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` diff --git a/docs/user-manual/en/rest.md b/docs/user-manual/en/rest.md index 7915eef0df..45059491a2 100644 --- a/docs/user-manual/en/rest.md +++ b/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 diff --git a/docs/user-manual/en/security.md b/docs/user-manual/en/security.md index 63e49a6c0a..0ac37c4562 100644 --- a/docs/user-manual/en/security.md +++ b/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=`.