This is an automated email from the ASF dual-hosted git repository.
andor pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/zookeeper.git
The following commit(s) were added to refs/heads/master by this push:
new a80f9b2 ZOOKEEPER-3636: find back the missing configuration
properties in the zookeeperAdmin page when moving from xml to markdown
a80f9b2 is described below
commit a80f9b291f2852b8dbe3b83bf2b5b4f0306424f5
Author: maoling <[email protected]>
AuthorDate: Tue Dec 17 20:12:52 2019 +0100
ZOOKEEPER-3636: find back the missing configuration properties in the
zookeeperAdmin page when moving from xml to markdown
- Compare to the
[zookeeperAdmin.xml](https://github.com/apache/zookeeper/pull/671/commits/9680f29f998197d3d1b66771e83736a84d643722#diff-5600ecd9735898b7607db6b1fd2f10c3)
of [ZOOKEEPER-3155](https://issues.apache.org/jira/browse/ZOOKEEPER-3155)
- more details in the
[ZOOKEEPER-3636](https://issues.apache.org/jira/browse/ZOOKEEPER-3636)
Author: maoling <[email protected]>
Reviewers: [email protected], [email protected]
Closes #1163 from maoling/ZOOKEEPER-3636
---
.../src/main/resources/markdown/zookeeperAdmin.md | 81 +++++++++++++++++++++-
1 file changed, 80 insertions(+), 1 deletion(-)
diff --git a/zookeeper-docs/src/main/resources/markdown/zookeeperAdmin.md
b/zookeeper-docs/src/main/resources/markdown/zookeeperAdmin.md
index 08a054e..e3e41cf 100644
--- a/zookeeper-docs/src/main/resources/markdown/zookeeperAdmin.md
+++ b/zookeeper-docs/src/main/resources/markdown/zookeeperAdmin.md
@@ -768,6 +768,71 @@ property, when available, is noted below.
of the observers on restart. Set to "false" to disable this
feature. Default is "true"
+* *extendedTypesEnabled* :
+ (Java system property only: **zookeeper.extendedTypesEnabled**)
+ **New in 3.5.4, 3.6.0:** Define to `true` to enable
+ extended features such as the creation of [TTL
Nodes](zookeeperProgrammers.html#TTL+Nodes).
+ They are disabled by default. IMPORTANT: when enabled server IDs must
+ be less than 255 due to internal limitations.
+
+* *emulate353TTLNodes* :
+ (Java system property only:**zookeeper.emulate353TTLNodes**).
+ **New in 3.5.4, 3.6.0:** Due to [ZOOKEEPER-2901]
+ (https://issues.apache.org/jira/browse/ZOOKEEPER-2901) TTL nodes
+ created in version 3.5.3 are not supported in 3.5.4/3.6.0. However, a
workaround is provided via the
+ zookeeper.emulate353TTLNodes system property. If you used TTL nodes in
ZooKeeper 3.5.3 and need to maintain
+ compatibility set **zookeeper.emulate353TTLNodes** to `true` in addition to
+ **zookeeper.extendedTypesEnabled**. NOTE: due to the bug, server IDs
+ must be 127 or less. Additionally, the maximum support TTL value is
`1099511627775` which is smaller
+ than what was allowed in 3.5.3 (`1152921504606846975`)
+
+* *watchManaggerName* :
+ (Java system property only: **zookeeper.watchManagerName**)
+ **New in 3.6.0:** Added in
[ZOOKEEPER-1179](https://issues.apache.org/jira/browse/ZOOKEEPER-1179)
+ New watcher manager WatchManagerOptimized is added to optimize the memory
overhead in heavy watch use cases. This
+ config is used to define which watcher manager to be used. Currently, we
only support WatchManager and
+ WatchManagerOptimized.
+
+* *watcherCleanThreadsNum* :
+ (Java system property only: **zookeeper.watcherCleanThreadsNum**)
+ **New in 3.6.0:** Added in
[ZOOKEEPER-1179](https://issues.apache.org/jira/browse/ZOOKEEPER-1179)
+ The new watcher manager WatchManagerOptimized will clean up the dead
watchers lazily, this config is used to decide how
+ many thread is used in the WatcherCleaner. More thread usually means larger
clean up throughput. The
+ default value is 2, which is good enough even for heavy and continuous
session closing/recreating cases.
+
+* *watcherCleanThreshold* :
+ (Java system property only: **zookeeper.watcherCleanThreshold**)
+ **New in 3.6.0:** Added in
[ZOOKEEPER-1179](https://issues.apache.org/jira/browse/ZOOKEEPER-1179)
+ The new watcher manager WatchManagerOptimized will clean up the dead
watchers lazily, the clean up process is relatively
+ heavy, batch processing will reduce the cost and improve the performance.
This setting is used to decide
+ the batch size. The default one is 1000, we don't need to change it if there
is no memory or clean up
+ speed issue.
+
+* *watcherCleanIntervalInSeconds* :
+ (Java system property only:**zookeeper.watcherCleanIntervalInSeconds**)
+ **New in 3.6.0:** Added in
[ZOOKEEPER-1179](https://issues.apache.org/jira/browse/ZOOKEEPER-1179)
+ The new watcher manager WatchManagerOptimized will clean up the dead
watchers lazily, the clean up process is relatively
+ heavy, batch processing will reduce the cost and improve the performance.
Besides watcherCleanThreshold,
+ this setting is used to clean up the dead watchers after certain time even
the dead watchers are not larger
+ than watcherCleanThreshold, so that we won't leave the dead watchers there
for too long. The default setting
+ is 10 minutes, which usually don't need to be changed.
+
+* *maxInProcessingDeadWatchers* :
+ (Java system property only: **zookeeper.maxInProcessingDeadWatchers**)
+ **New in 3.6.0:** Added in
[ZOOKEEPER-1179](https://issues.apache.org/jira/browse/ZOOKEEPER-1179)
+ This is used to control how many backlog can we have in the WatcherCleaner,
when it reaches this number, it will
+ slow down adding the dead watcher to WatcherCleaner, which will in turn slow
down adding and closing
+ watchers, so that we can avoid OOM issue. By default there is no limit, you
can set it to values like
+ watcherCleanThreshold * 1000.
+
+* *bitHashCacheSize* :
+ (Java system property only: **zookeeper.bitHashCacheSize**)
+ **New 3.6.0**: Added in
[ZOOKEEPER-1179](https://issues.apache.org/jira/browse/ZOOKEEPER-1179)
+ This is the setting used to decide the HashSet cache size in the BitHashSet
implementation. Without HashSet, we
+ need to use O(N) time to get the elements, N is the bit numbers in
elementBits. But we need to
+ keep the size small to make sure it doesn't cost too much in memory, there
is a trade off between memory
+ and time complexity. The default value is 10, which seems a relatively
reasonable cache size.
+
* *fastleader.minNotificationInterval* :
(Java system property: **zookeeper.fastleader.minNotificationInterval**)
Lower bound for length of time between two consecutive notification
@@ -875,7 +940,8 @@ property, when available, is noted below.
The weight of renewing a session. It is also the number of tokens required
for a reconnect request to get through the throttler. It has to be a positive
integer no smaller than the weight of a local session. The default is 2.
- * *clientPortListenBacklog* :
+* *clientPortListenBacklog* :
+ (No Java system property)
**New in 3.4.14, 3.5.5, 3.6.0:**
The socket backlog length for the ZooKeeper server socket. This controls
the number of requests that will be queued server-side to be processed
@@ -1032,6 +1098,19 @@ of servers -- that is, when deploying clusters of
servers.
of removing them in the next release, at which point only the
FastLeaderElection will be available.
+* *maxTimeToWaitForEpoch* :
+ (Java system property: **zookeeper.leader.maxTimeToWaitForEpoch**)
+ **New in 3.6.0:**
+ The maximum time to wait for epoch from voters when activating
+ leader. If leader received a LOOKING notification from one of
+ it's voters, and it hasn't received epoch packets from majority
+ within maxTimeToWaitForEpoch, then it will goto LOOKING and
+ elect leader again.
+ This can be tuned to reduce the quorum or server unavailable
+ time, it can be set to be much smaller than initLimit * tickTime.
+ In cross datacenter environment, it can be set to something
+ like 2s.
+
* *initLimit* :
(No Java system property)
Amount of time, in ticks (see [tickTime](#id_tickTime)), to allow
followers to
