reschke commented on code in PR #1948: URL: https://github.com/apache/jackrabbit-oak/pull/1948#discussion_r1906964407
########## oak-doc/src/site/markdown/nodestore/documentmk.md: ########## @@ -773,6 +773,22 @@ the `machine` and `instance` fields. This behaviour is new and was introduced with Oak 1.10. Previous versions ignore entries that do not match the environment and would create a new entry. +Note that while this behavior is usually beneficial, there are circumstances +under which it may lead to very slow startup times for cluster nodes that try +to acquire a node ID that has not been shut down gracefully and has been +inactive for a long time. This is due to synchronous recovery operations that +are necessary to guarantee the consistency of the cluster (for details see +[Recovery for a cluster node ID](#recovery-for-a-cluster-node-id)). + +To avoid that, the maximum duration of the synchronous recovery may be +limited using the system property `oak.documentMK.syncRecoveryTimeoutMillis`. +A positive value will specify this maximum duration in milliseconds, while a +negative value doesn't limit the recovery time. The default is `-1`. +If the duration is exceeded, the node will no longer try to reuse the ID +and pick one that doesn't need recovery. Note that this feature has been +specifically designed for a certain unusual Oak deployment and is not Review Comment: ```suggestion specifically designed for unusual Oak deployments (requiring significantly longer lease timeouts) and is not ``` ########## oak-doc/src/site/markdown/nodestore/documentmk.md: ########## @@ -773,6 +773,22 @@ the `machine` and `instance` fields. This behaviour is new and was introduced with Oak 1.10. Previous versions ignore entries that do not match the environment and would create a new entry. +Note that while this behavior is usually beneficial, there are circumstances +under which it may lead to very slow startup times for cluster nodes that try +to acquire a node ID that has not been shut down gracefully and has been +inactive for a long time. This is due to synchronous recovery operations that +are necessary to guarantee the consistency of the cluster (for details see +[Recovery for a cluster node ID](#recovery-for-a-cluster-node-id)). + +To avoid that, the maximum duration of the synchronous recovery may be +limited using the system property `oak.documentMK.syncRecoveryTimeoutMillis`. +A positive value will specify this maximum duration in milliseconds, while a +negative value doesn't limit the recovery time. The default is `-1`. +If the duration is exceeded, the node will no longer try to reuse the ID +and pick one that doesn't need recovery. Note that this feature has been Review Comment: ```suggestion and pick one that doesn't need recovery. Note that this feature has been ``` -- 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: oak-dev-unsubscr...@jackrabbit.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
