[
https://issues.apache.org/jira/browse/ZOOKEEPER-3829?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
benwang li updated ZOOKEEPER-3829:
----------------------------------
Description:
It's easy to reproduce this bug.
{code:java}
//代码占位符
Step 1. Deploy 3 nodes A,B,C with configuration A,B,C .
Step 2. Deploy node ` D` with configuration `A,B,C,D` , cluster state is ok
now.
Step 3. Restart nodes A,B,C with configuration A,B,C,D, then the leader will be
D, cluster hangs.
Step 4. Restart nodes D, cluster state is back to normal now.
{code}
We have looked into the code of 3.5.6 version, and we found it may be the issue
of `workerPool` .
The `CommitProcessor` shutdown and make `workerPool` shutdown, but `workerPool`
still exists. It will never work anymore, yet the cluster still thinks it's ok.
I think the bug may still exist in master branch.
was:
It's easy to reproduce this bug.
{code:java}
//代码占位符
Step 1. Deploy 3 nodes A,B,C with configuration A,B,C .
Step 2. Deploy node ` D` with configuration `A,B,C,D` , cluster state is ok
now.
Step 3. Restart nodes A,B,C with configuration A,B,C,D, then the leader will be
D, cluster hangs.
Step 4. Restart nodes D, cluster state is back to normal now.
{code}
We have looked into the code of 3.6.5 version, and we found it may be the issue
of `workerPool` .
The `CommitProcessor` shutdown and make `workerPool` shutdown, but `workerPool`
still exists. It will never work anymore, yet the cluster still thinks it's ok.
I think the bug may still exist in master branch.
> Zookeeper refuses request after node expansion
> ----------------------------------------------
>
> Key: ZOOKEEPER-3829
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3829
> Project: ZooKeeper
> Issue Type: Bug
> Components: server
> Affects Versions: 3.5.6
> Reporter: benwang li
> Priority: Major
>
> It's easy to reproduce this bug.
> {code:java}
> //代码占位符
>
> Step 1. Deploy 3 nodes A,B,C with configuration A,B,C .
> Step 2. Deploy node ` D` with configuration `A,B,C,D` , cluster state is ok
> now.
> Step 3. Restart nodes A,B,C with configuration A,B,C,D, then the leader will
> be D, cluster hangs.
> Step 4. Restart nodes D, cluster state is back to normal now.
>
> {code}
>
> We have looked into the code of 3.5.6 version, and we found it may be the
> issue of `workerPool` .
> The `CommitProcessor` shutdown and make `workerPool` shutdown, but
> `workerPool` still exists. It will never work anymore, yet the cluster still
> thinks it's ok.
>
> I think the bug may still exist in master branch.
>
>
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
