You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@pulsar.apache.org by GitBox <gi...@apache.org> on 2021/12/13 07:51:58 UTC

[GitHub] [pulsar] Anonymitaet commented on a change in pull request #13230: feat(docs): add more limitations for replicated subscriptions

Anonymitaet commented on a change in pull request #13230:
URL: https://github.com/apache/pulsar/pull/13230#discussion_r767478337



##########
File path: site2/docs/administration-geo.md
##########
@@ -214,4 +214,5 @@ Consumer<String> consumer = client.newConsumer(Schema.STRING)
 
 ### Limitations
 
-When you enable replicated subscription, you're creating a consistent distributed snapshot to establish an association between message ids from different clusters. The snapshots are taken periodically. The default value is `1 second`. It means that a consumer failing over to a different cluster can potentially receive 1 second of duplicates. You can also configure the frequency of the snapshot in the `broker.conf` file.
+* When you enable replicated subscription, you're creating a consistent distributed snapshot to establish an association between message ids from different clusters. The snapshots are taken periodically. The default value is `1 second`. It means that a consumer failing over to a different cluster can potentially receive 1 second of duplicates. You can also configure the frequency of the snapshot in the `broker.conf` file.
+* Only the base line cursor position will be synced in replicated subscriptions while the individual  acknowledgments won't be synced. This that the messages acknowledged out-of-order could end up getting delivered again, in the case of a cluster failover.

Review comment:
       ```suggestion
   * Only the base line cursor position is synced in replicated subscriptions while the individual acknowledgments are not synced. This means the messages acknowledged out-of-order could end up getting delivered again, in the case of a cluster failover.
   ```
   
   - Always use the present tense in technical writing by default. 
   - Use present tense if you are covering facts that were, are, and forever shall be true.
   - Only use past or future tenses when you’re actually writing about something that happened in the past or will happen in the future.
   




-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscribe@pulsar.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org