Jialin Chen created ZOOKEEPER-5105:
--------------------------------------
Summary: zkCli addWatch reuses the mode of a previous invocation
when -m is omitted
Key: ZOOKEEPER-5105
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-5105
Project: ZooKeeper
Issue Type: Bug
Components: java client
Affects Versions: 3.10.0, 3.8.7, 3.9.6
Reporter: Jialin Chen
zkCli keeps a single instance of each CLI command for the whole session, and
{{AddWatchCommand.parse()}} only assigns the {{mode}} field when {{-m}} is
given. After an {{addWatch -m PERSISTENT ...}}, every later {{addWatch}}
without {{-m}} in the same session registers a {{PERSISTENT}} watch instead of
the default {{PERSISTENT_RECURSIVE}} that the usage text announces ("default is
PERSISTENT_RECURSIVE").
Steps to reproduce (standalone server built from master at 48f7cb00e):
{noformat}
[zk: localhost:22181(CONNECTED) 0] create /w1 x
[zk: localhost:22181(CONNECTED) 1] create /w2 x
[zk: localhost:22181(CONNECTED) 2] addWatch -m PERSISTENT /w1
[zk: localhost:22181(CONNECTED) 3] addWatch /w2
[zk: localhost:22181(CONNECTED) 4] create /w2/c x
WatchedEvent state:SyncConnected type:NodeChildrenChanged path:/w2 zxid: 35
{noformat}
Expected: {{addWatch /w2}} registers a persistent recursive watch, so creating
{{/w2/c}} fires {{NodeCreated path:/w2/c}}. This is what a fresh session gets:
{noformat}
[zk: localhost:22181(CONNECTED) 0] create /w3 x
[zk: localhost:22181(CONNECTED) 1] addWatch /w3
[zk: localhost:22181(CONNECTED) 2] create /w3/c x
WatchedEvent state:SyncConnected type:NodeCreated path:/w3/c zxid: 38
{noformat}
Actual: the watch on {{/w2}} is a plain persistent watch, so only
{{NodeChildrenChanged path:/w2}} fires.
The behaviour dates back to the introduction of the command in ZOOKEEPER-1416
(3.6.0). {{ReconfigCommand.parse()}} already resets its per-invocation fields
for the same reason; {{AddWatchCommand.parse()}} should fall back to the
default mode when {{-m}} is absent.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
