This is an automated email from the ASF dual-hosted git repository.
brusdev pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/activemq-artemis.git
The following commit(s) were added to refs/heads/main by this push:
new 3db843a760 NO-JIRA Minor corrections to the HA documentation page
3db843a760 is described below
commit 3db843a7605f2e6dd26958c6457e296783cf66b1
Author: ALX <[email protected]>
AuthorDate: Mon Feb 13 01:54:03 2023 +0500
NO-JIRA Minor corrections to the HA documentation page
---
docs/user-manual/en/ha.md | 23 +++++++++++------------
1 file changed, 11 insertions(+), 12 deletions(-)
diff --git a/docs/user-manual/en/ha.md b/docs/user-manual/en/ha.md
index 03827a5e29..694875c9f5 100644
--- a/docs/user-manual/en/ha.md
+++ b/docs/user-manual/en/ha.md
@@ -869,7 +869,7 @@ like:
In this instance the server is configured to use a specific connector to
scale down, if a connector is not specified then the first INVM
-connector is chosen, this is to make scale down fromm a backup server
+connector is chosen, this is to make scale down from a backup server
easy to configure. It is also possible to use discovery to scale down,
this would look like:
@@ -909,9 +909,9 @@ It is also possible to mix scale down with HA via backup
servers. If a
slave is configured to scale down then after failover has occurred,
instead of starting fully the backup server will immediately scale down
to another live server. The most appropriate configuration for this is
-using the `colocated` approach. it means as you bring up live server
-they will automatically be backed up by server and as live servers are
-shutdown, there messages are made available on another live server. A
+using the `colocated` approach. It means that as you bring up live servers
+they will automatically be backed up, and as live servers are
+shutdown, their messages are made available on another live server. A
typical configuration would look like:
```xml
@@ -952,7 +952,7 @@ When a server is stopping and preparing to scale down it
will send a
message to all its clients informing them which server it is scaling
down to before disconnecting them. At this point the client will
reconnect however this will only succeed once the server has completed
-scaledown. This is to ensure that any state such as queues or
+the scaledown process. This is to ensure that any state such as queues or
transactions are there for the client when it reconnects. The normal
reconnect settings apply when the client is reconnecting so these should
be high enough to deal with the time needed to scale down.
@@ -971,9 +971,8 @@ problems). This is similar to failover, except it is
reconnecting to the
same server and is discussed in [Client Reconnection and Session
Reattachment](client-reconnection.md)
During failover, if the client has consumers on any non persistent or
-temporary queues, those queues will be automatically recreated during
-failover on the backup node, since the backup node will not have any
-knowledge of non persistent queues.
+temporary queues, those queues will be automatically recreated on the backup
node,
+since the backup node will not have any knowledge of non persistent queues.
### Automatic Client Failover
@@ -1138,17 +1137,17 @@ getting sent more than once.
> **Note:**
>
> By catching the rollback exceptions and retrying, catching unblocked
-> calls and enabling duplicate detection, once and only once delivery
-> guarantees for messages can be provided in the case of failure,
+> calls and enabling duplicate detection, *once and only once* delivery
+> guarantees can be provided for messages in the case of failure,
> guaranteeing 100% no loss or duplication of messages.
#### Handling Failover With Non Transactional Sessions
If the session is non transactional, messages or acknowledgements can be
-lost in the event of failover.
+lost in the event of a failover.
If you wish to provide *once and only once* delivery guarantees for non
-transacted sessions too, enabled duplicate detection, and catch unblock
+transacted sessions too, enable duplicate detection, and catch unblock
exceptions as described in [Handling Blocking Calls During Failover](ha.md)
### Getting Notified of Connection Failure
