[jira] [Commented] (ZOOKEEPER-3607) Potential data inconsistency due to the inconsistency between ZKDatabase.committedLog and dataTree in Trunc sync.

2019-11-11 Thread Jiafu Jiang (Jira)


[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-3607?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16972124#comment-16972124
 ] 

Jiafu Jiang commented on ZOOKEEPER-3607:


And I have fixed this problem in my personal branch, see 
[https://github.com/jiafujiang/zookeeper/commit/6bd9ad1d3c0c615183d83beb80a6129365d52c42]
 for my patch.

> Potential data inconsistency due to the inconsistency between 
> ZKDatabase.committedLog and dataTree in Trunc sync.
> -
>
> Key: ZOOKEEPER-3607
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3607
> Project: ZooKeeper
>  Issue Type: Bug
>  Components: quorum
>Affects Versions: 3.4.14
>Reporter: Jiafu Jiang
>Priority: Critical
>
> I will describe the problem by a detail example.
> 1. Suppose we have three zk servers: zk1, zk2, and zk3. zk1 and zk2 are 
> online, zk3 is offline, zk1 is the leader.
> 2. In TRUNC sync, zk1 sends a TRUNC request to zk2, then sends the remaining 
> proposals in the committedLog. *When the follower zk2 receives the proposals, 
> it applies them directly into the datatree, but not the committedLog.*
> 3. After the data sync phase, zk1 may continue to send zk2 more committed 
> proposals, and they will be applied to both the datatree and the committedLog 
> of zk2.
> 4. Then zk1 fails, zk3 restarts successfully, zk2 becomes the leader.
> 5. The leader zk2 sends a TRUNC request to zk3, then the remaining proposals 
> from the committedLog. But since some proposals, which are from the leader 
> zk1 in TRUNC sync(as I describe above), are not in the committedLog, they 
> will not be sent to zk3.
> 6. Now data inconsistency happens between zk2 and zk3, since some data may 
> exist in zk2's datatree, but not zk3's datatree.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (ZOOKEEPER-3607) Potential data inconsistency due to the inconsistency between ZKDatabase.committedLog and dataTree in Trunc sync.

2019-11-11 Thread Jiafu Jiang (Jira)


[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-3607?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16972105#comment-16972105
 ] 

Jiafu Jiang commented on ZOOKEEPER-3607:


I can reproduce this problem in the following steps:
1. Clear all data of zk1, zk2 and zk3, including all the data under the data 
dir and log dir.
2. Start zk1 and zk3, zk3 will become the leader, because zk3 has a larger ID.
3. Start zk2.
4. Create "/a". Now "/a" will exist in zk1, zk2, and zk3.
5. Stop zk2: bin/zkServer.sh stop.
6. Create "/b". Now "/a" and "/b" will exist in both zk1 and zk3.
7. Stop zk1 and zk3, and delete all data of zk1.
8. Start zk1 and zk2. Because zk2 has more recent data, so zk2 will become the 
leader. Now zk1 and zk2 both have data "/a".
9. Create "/c". Now zk1 and zk2 both have data "/a" and "/c".
9. Backup all the data of zk3 to /tmp. 
10.Start zk3. Zk3 will synchronize data with the leader(zk2), so "/b" will be 
truncated, and zk3 will receive "/c" from zk2. And zk3 will apply "/c" to the 
datatree, but not ZKDatabase.committedLog.
11.Stop zk2(the leader). Because zk1 and zk3 have the same max zxid, so zk3 
will become the leader since it has a larger ID. 
12. Repalce zk2's data using the backup that we save in step 9. Remember to 
change the myid to 2.
13. Start zk2. Zk2 will become a follower, and try to synchronize with the 
leader(zk3). Zk3 will send a TRUNC to zk2 to truncate the "/b", but zk3 will 
not send "/c" to zk2, because "/c" does not exist in zk3's 
ZKDatabase.committedLog.
14. Now if you use "bin/zkCli.sh ls /" on the node of zk2, you can not see 
"/c", but you can see it from both zk1 and zk3.

> Potential data inconsistency due to the inconsistency between 
> ZKDatabase.committedLog and dataTree in Trunc sync.
> -
>
> Key: ZOOKEEPER-3607
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3607
> Project: ZooKeeper
>  Issue Type: Bug
>  Components: quorum
>Affects Versions: 3.4.14
>Reporter: Jiafu Jiang
>Priority: Critical
>
> I will describe the problem by a detail example.
> 1. Suppose we have three zk servers: zk1, zk2, and zk3. zk1 and zk2 are 
> online, zk3 is offline, zk1 is the leader.
> 2. In TRUNC sync, zk1 sends a TRUNC request to zk2, then sends the remaining 
> proposals in the committedLog. *When the follower zk2 receives the proposals, 
> it applies them directly into the datatree, but not the committedLog.*
> 3. After the data sync phase, zk1 may continue to send zk2 more committed 
> proposals, and they will be applied to both the datatree and the committedLog 
> of zk2.
> 4. Then zk1 fails, zk3 restarts successfully, zk2 becomes the leader.
> 5. The leader zk2 sends a TRUNC request to zk3, then the remaining proposals 
> from the committedLog. But since some proposals, which are from the leader 
> zk1 in TRUNC sync(as I describe above), are not in the committedLog, they 
> will not be sent to zk3.
> 6. Now data inconsistency happens between zk2 and zk3, since some data may 
> exist in zk2's datatree, but not zk3's datatree.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (ZOOKEEPER-3611) strengthen CLI:addWatch to support all watch event type and add a documentation

2019-11-11 Thread maoling (Jira)


[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-3611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16971994#comment-16971994
 ] 

maoling commented on ZOOKEEPER-3611:


[~randgalt]

Yep, let me try this job :)

> strengthen CLI:addWatch to support all watch event type and add a 
> documentation
> ---
>
> Key: ZOOKEEPER-3611
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3611
> Project: ZooKeeper
>  Issue Type: Improvement
>Reporter: maoling
>Assignee: maoling
>Priority: Major
>




--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (ZOOKEEPER-3594) Ability to skip proposing requests with error transactions

2019-11-11 Thread Fangmin Lv (Jira)


[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-3594?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16971779#comment-16971779
 ] 

Fangmin Lv commented on ZOOKEEPER-3594:
---

[~hanm] this is the skip error txn feature I mentioned in your ACL skip Jira, 
Vlad spent lots of effort to make this working, which proved to improve a lot 
of efficiency in ZK for traffic pattern which may have lots of errors.

Vlad will upstream this feature soon, please help review.

> Ability to skip proposing requests with error transactions
> --
>
> Key: ZOOKEEPER-3594
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3594
> Project: ZooKeeper
>  Issue Type: New Feature
>  Components: quorum, server
>Affects Versions: 3.5.6
>Reporter: Vladimir Ivić
>Assignee: Vladimir Ivić
>Priority: Major
>
> Ensembles that have a high write request rate could be skipping proposing 
> requests that contain errors instead of having the quorum vote on those 
> transactions.
> For example, having a sizable write traffic that results in error 
> transactions would be creating additional network and log disk space overhead 
> for each of the requests that would only return errors to the client in the 
> end (e.g. delete non-existing path, version mismatch, trying to create a node 
> that already exists etc). 
> Currently, there is no such logic in the ProposalRequestProcessor, every 
> request that comes out of PrepRequestProcessor will be proposed to the 
> quorum.  
> Proposed solution workflow:
>  * A client sends a new write request trying to setData on an non-existing 
> node
>  * The server accepts the request and sends it through the 
> PrepRequestProcessor
>  * PrepRequestProcessor detects the error and assigns the error transaction 
> to the request
>  * Between PrepRequestProcessor and ProposalRequestProcessor there is another 
> processor named SkipRequestProcessor which sole responsibility is to decide 
> will the request be forwarded or returned to the originating quorum peer 
> (Leader or Learner).
>  * The quorum peer waits for all previous requests to complete before the 
> error request proceeds with echoing the error back to the client.
> Requirements: 
>  * We should be conservative about the use of ZXID. If the request generates 
> an error transaction we don't want to increment the last proposed ZXID and 
> cause any gaps in the log.
>  * Request that are found to be invalid should be sent directly to the origin 
> (either to the corresponding Learner or to the Leader directly) so there is 
> exactly one roundtrip for each request with error transaction.
>  * All the requests must preserve its order, the changes must be backwards 
> compatible with the Zookeeper ordering guarantees. 
>  Challenges:
>  * Skipping request without having them go through the proposal pipeline 
> poses a challenge in preserving Zookeeper transaction order.
>  * Avoiding any additional changes inside CommitProcessor if possible.
>  * Have unified logic for all three different paths in which write requests 
> can come through:
>  ## Via Leader placed directly into the PrepRequestProcessor
>  ## Via Follower where the request is forwarded to the leader and also passed 
> to CommitProcessor to wait for COMMIT packet
>  ## Via Observer, where the request is forwarded to the Leader and the 
> Observer waits for the INFORM packet



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (ZOOKEEPER-3598) Fix potential data inconsistency issue due to CommitProcessor not gracefully shutdown

2019-11-11 Thread Hudson (Jira)


[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-3598?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16971763#comment-16971763
 ] 

Hudson commented on ZOOKEEPER-3598:
---

FAILURE: Integrated in Jenkins build ZooKeeper-trunk #769 (See 
[https://builds.apache.org/job/ZooKeeper-trunk/769/])
ZOOKEEPER-3598: Fix potential data inconsistency issue due to (eolivelli: rev 
79f99af81842f415b97e1c3c18c953df5bd129b2)
* (edit) 
zookeeper-server/src/main/java/org/apache/zookeeper/server/ExitCode.java
* (edit) 
zookeeper-server/src/test/java/org/apache/zookeeper/server/quorum/CommitProcessorTest.java
* (edit) 
zookeeper-server/src/main/java/org/apache/zookeeper/server/quorum/CommitProcessor.java


>  Fix potential data inconsistency issue due to CommitProcessor not gracefully 
> shutdown
> --
>
> Key: ZOOKEEPER-3598
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3598
> Project: ZooKeeper
>  Issue Type: Bug
>  Components: server
>Affects Versions: 3.6.0
>Reporter: Fangmin Lv
>Assignee: Fangmin Lv
>Priority: Critical
>  Labels: pull-request-available
> Fix For: 3.6.0
>
>  Time Spent: 1h 10m
>  Remaining Estimate: 0h
>
>  
> There was a regression introduced after inline the write in CommitProcessor 
> with changes intorduced in ZOOKEEPER-3359, which didn't wait the in-flight 
> write to finish before calling shutdown on the nextProcessor.
>  
> So it's possible that CommitProcessor thread and QuorumPeer thread will 
> update the DataTree concurrently if we're doing fastForwardDataBase at the 
> end of ZooKeeperServer.shutdown, which will cause inconsistent issue.
>  
> This JIRA is going to make sure we wait on the CommitProcessor to shutdown 
> gracefully before calling shutdown on next processor, and exit if we cannot 
> finish it gracefully to avoid potential inconsistency.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (ZOOKEEPER-1260) Audit logging in ZooKeeper servers.

2019-11-11 Thread Hudson (Jira)


[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-1260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16971764#comment-16971764
 ] 

Hudson commented on ZOOKEEPER-1260:
---

FAILURE: Integrated in Jenkins build ZooKeeper-trunk #769 (See 
[https://builds.apache.org/job/ZooKeeper-trunk/769/])
ZOOKEEPER-1260: Audit logging in ZooKeeper servers. (eolivelli: rev 
794adf11220151496a1ff877df3d2627719c9505)
* (add) 
zookeeper-server/src/main/java/org/apache/zookeeper/audit/AuditEvent.java
* (add) 
zookeeper-server/src/main/java/org/apache/zookeeper/audit/ZKAuditProvider.java
* (add) 
zookeeper-server/src/test/java/org/apache/zookeeper/audit/Log4jAuditLoggerTest.java
* (add) 
zookeeper-server/src/main/java/org/apache/zookeeper/audit/Log4jAuditLogger.java
* (edit) 
zookeeper-server/src/main/java/org/apache/zookeeper/server/auth/AuthenticationProvider.java
* (edit) 
zookeeper-server/src/main/java/org/apache/zookeeper/server/quorum/QuorumPeerMain.java
* (edit) 
zookeeper-server/src/main/java/org/apache/zookeeper/server/ServerCnxnFactory.java
* (edit) 
zookeeper-server/src/main/java/org/apache/zookeeper/server/ZooKeeperServerMain.java
* (add) 
zookeeper-server/src/main/java/org/apache/zookeeper/audit/AuditHelper.java
* (edit) 
zookeeper-server/src/main/java/org/apache/zookeeper/server/ServerCnxn.java
* (add) 
zookeeper-server/src/test/java/org/apache/zookeeper/server/util/AuthUtilTest.java
* (add) 
zookeeper-server/src/main/java/org/apache/zookeeper/audit/AuditConstants.java
* (add) 
zookeeper-server/src/main/java/org/apache/zookeeper/audit/AuditLogger.java
* (add) zookeeper-docs/src/main/resources/markdown/images/zkAuditLogs.jpg
* (edit) zookeeper-server/src/main/java/org/apache/zookeeper/Login.java
* (edit) 
zookeeper-server/src/main/java/org/apache/zookeeper/server/FinalRequestProcessor.java
* (add) 
zookeeper-server/src/test/java/org/apache/zookeeper/audit/ZKAuditLoggerPerformance.java
* (edit) zookeeper-docs/src/main/resources/markdown/index.md
* (edit) zookeeper-docs/src/main/resources/markdown/zookeeperAdmin.md
* (add) 
zookeeper-server/src/test/java/org/apache/zookeeper/audit/AuditEventTest.java
* (edit) zookeeper-docs/src/main/resources/markdown/html/header.html
* (edit) zookeeper-server/src/main/java/org/apache/zookeeper/ZKUtil.java
* (edit) 
zookeeper-server/src/main/java/org/apache/zookeeper/cli/GetAclCommand.java
* (edit) zookeeper-server/src/main/java/org/apache/zookeeper/server/Request.java
* (edit) 
zookeeper-server/src/main/java/org/apache/zookeeper/server/auth/DigestAuthenticationProvider.java
* (edit) conf/log4j.properties
* (add) 
zookeeper-server/src/main/java/org/apache/zookeeper/server/util/AuthUtil.java
* (edit) 
zookeeper-server/src/main/java/org/apache/zookeeper/server/DataTree.java
* (add) 
zookeeper-server/src/test/java/org/apache/zookeeper/audit/AuditLogPerfReading.java
* (add) zookeeper-docs/src/main/resources/markdown/zookeeperAuditLogs.md


> Audit logging in ZooKeeper servers.
> ---
>
> Key: ZOOKEEPER-1260
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1260
> Project: ZooKeeper
>  Issue Type: New Feature
>  Components: server
>Reporter: Mahadev Konar
>Assignee: Mohammad Arshad
>Priority: Major
>  Labels: pull-request-available
> Fix For: 3.6.0
>
> Attachments: ZOOKEEPER-1260-01.patch, zookeeperAuditLogs.pdf
>
>  Time Spent: 11h 10m
>  Remaining Estimate: 0h
>
> Lots of users have had questions on debugging which client changed what znode 
> and what updates went through a znode. We should add audit logging as in 
> Hadoop (look at Namenode Audit logging) to log which client changed what in 
> the zookeeper servers. This could just be a log4j audit logger.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (ZOOKEEPER-3598) Fix potential data inconsistency issue due to CommitProcessor not gracefully shutdown

2019-11-11 Thread Hudson (Jira)


[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-3598?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16971749#comment-16971749
 ] 

Hudson commented on ZOOKEEPER-3598:
---

FAILURE: Integrated in Jenkins build Zookeeper-trunk-single-thread #608 (See 
[https://builds.apache.org/job/Zookeeper-trunk-single-thread/608/])
ZOOKEEPER-3598: Fix potential data inconsistency issue due to (eolivelli: rev 
79f99af81842f415b97e1c3c18c953df5bd129b2)
* (edit) 
zookeeper-server/src/main/java/org/apache/zookeeper/server/quorum/CommitProcessor.java
* (edit) 
zookeeper-server/src/main/java/org/apache/zookeeper/server/ExitCode.java
* (edit) 
zookeeper-server/src/test/java/org/apache/zookeeper/server/quorum/CommitProcessorTest.java


>  Fix potential data inconsistency issue due to CommitProcessor not gracefully 
> shutdown
> --
>
> Key: ZOOKEEPER-3598
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3598
> Project: ZooKeeper
>  Issue Type: Bug
>  Components: server
>Affects Versions: 3.6.0
>Reporter: Fangmin Lv
>Assignee: Fangmin Lv
>Priority: Critical
>  Labels: pull-request-available
> Fix For: 3.6.0
>
>  Time Spent: 1h 10m
>  Remaining Estimate: 0h
>
>  
> There was a regression introduced after inline the write in CommitProcessor 
> with changes intorduced in ZOOKEEPER-3359, which didn't wait the in-flight 
> write to finish before calling shutdown on the nextProcessor.
>  
> So it's possible that CommitProcessor thread and QuorumPeer thread will 
> update the DataTree concurrently if we're doing fastForwardDataBase at the 
> end of ZooKeeperServer.shutdown, which will cause inconsistent issue.
>  
> This JIRA is going to make sure we wait on the CommitProcessor to shutdown 
> gracefully before calling shutdown on next processor, and exit if we cannot 
> finish it gracefully to avoid potential inconsistency.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (ZOOKEEPER-1260) Audit logging in ZooKeeper servers.

2019-11-11 Thread Hudson (Jira)


[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-1260?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16971750#comment-16971750
 ] 

Hudson commented on ZOOKEEPER-1260:
---

FAILURE: Integrated in Jenkins build Zookeeper-trunk-single-thread #608 (See 
[https://builds.apache.org/job/Zookeeper-trunk-single-thread/608/])
ZOOKEEPER-1260: Audit logging in ZooKeeper servers. (eolivelli: rev 
794adf11220151496a1ff877df3d2627719c9505)
* (edit) zookeeper-docs/src/main/resources/markdown/html/header.html
* (edit) 
zookeeper-server/src/main/java/org/apache/zookeeper/server/ServerCnxnFactory.java
* (edit) 
zookeeper-server/src/main/java/org/apache/zookeeper/server/quorum/QuorumPeerMain.java
* (edit) zookeeper-docs/src/main/resources/markdown/index.md
* (add) zookeeper-docs/src/main/resources/markdown/zookeeperAuditLogs.md
* (edit) 
zookeeper-server/src/main/java/org/apache/zookeeper/server/DataTree.java
* (edit) 
zookeeper-server/src/main/java/org/apache/zookeeper/server/ServerCnxn.java
* (add) zookeeper-docs/src/main/resources/markdown/images/zkAuditLogs.jpg
* (edit) zookeeper-server/src/main/java/org/apache/zookeeper/server/Request.java
* (add) 
zookeeper-server/src/test/java/org/apache/zookeeper/server/util/AuthUtilTest.java
* (add) 
zookeeper-server/src/main/java/org/apache/zookeeper/audit/AuditHelper.java
* (add) 
zookeeper-server/src/main/java/org/apache/zookeeper/server/util/AuthUtil.java
* (add) 
zookeeper-server/src/main/java/org/apache/zookeeper/audit/AuditLogger.java
* (edit) 
zookeeper-server/src/main/java/org/apache/zookeeper/server/FinalRequestProcessor.java
* (edit) 
zookeeper-server/src/main/java/org/apache/zookeeper/server/auth/DigestAuthenticationProvider.java
* (add) 
zookeeper-server/src/test/java/org/apache/zookeeper/audit/AuditEventTest.java
* (add) 
zookeeper-server/src/test/java/org/apache/zookeeper/audit/ZKAuditLoggerPerformance.java
* (edit) zookeeper-server/src/main/java/org/apache/zookeeper/Login.java
* (edit) 
zookeeper-server/src/main/java/org/apache/zookeeper/server/auth/AuthenticationProvider.java
* (add) 
zookeeper-server/src/test/java/org/apache/zookeeper/audit/AuditLogPerfReading.java
* (edit) zookeeper-docs/src/main/resources/markdown/zookeeperAdmin.md
* (add) 
zookeeper-server/src/main/java/org/apache/zookeeper/audit/AuditConstants.java
* (add) 
zookeeper-server/src/main/java/org/apache/zookeeper/audit/AuditEvent.java
* (edit) conf/log4j.properties
* (edit) 
zookeeper-server/src/main/java/org/apache/zookeeper/server/ZooKeeperServerMain.java
* (edit) zookeeper-server/src/main/java/org/apache/zookeeper/ZKUtil.java
* (add) 
zookeeper-server/src/main/java/org/apache/zookeeper/audit/Log4jAuditLogger.java
* (add) 
zookeeper-server/src/test/java/org/apache/zookeeper/audit/Log4jAuditLoggerTest.java
* (add) 
zookeeper-server/src/main/java/org/apache/zookeeper/audit/ZKAuditProvider.java
* (edit) 
zookeeper-server/src/main/java/org/apache/zookeeper/cli/GetAclCommand.java


> Audit logging in ZooKeeper servers.
> ---
>
> Key: ZOOKEEPER-1260
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1260
> Project: ZooKeeper
>  Issue Type: New Feature
>  Components: server
>Reporter: Mahadev Konar
>Assignee: Mohammad Arshad
>Priority: Major
>  Labels: pull-request-available
> Fix For: 3.6.0
>
> Attachments: ZOOKEEPER-1260-01.patch, zookeeperAuditLogs.pdf
>
>  Time Spent: 11h 10m
>  Remaining Estimate: 0h
>
> Lots of users have had questions on debugging which client changed what znode 
> and what updates went through a znode. We should add audit logging as in 
> Hadoop (look at Namenode Audit logging) to log which client changed what in 
> the zookeeper servers. This could just be a log4j audit logger.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (ZOOKEEPER-3611) strengthen CLI:addWatch to support all watch event type and add a documentation

2019-11-11 Thread Jordan Zimmerman (Jira)


[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-3611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16971534#comment-16971534
 ] 

Jordan Zimmerman commented on ZOOKEEPER-3611:
-

It occurs to me that the new ZooKeeper.addWatch() API could be extended to 
support all watch types as well. Thoughts?

> strengthen CLI:addWatch to support all watch event type and add a 
> documentation
> ---
>
> Key: ZOOKEEPER-3611
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3611
> Project: ZooKeeper
>  Issue Type: Improvement
>Reporter: maoling
>Assignee: maoling
>Priority: Major
>




--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Resolved] (ZOOKEEPER-3598) Fix potential data inconsistency issue due to CommitProcessor not gracefully shutdown

2019-11-11 Thread Enrico Olivelli (Jira)


 [ 
https://issues.apache.org/jira/browse/ZOOKEEPER-3598?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Enrico Olivelli resolved ZOOKEEPER-3598.

Release Note: 
Committed to master branch as 79f99af81842f415b97e1c3c18c953df5bd129b2

(I had a problem with the script and JIRA)
  Resolution: Fixed

>  Fix potential data inconsistency issue due to CommitProcessor not gracefully 
> shutdown
> --
>
> Key: ZOOKEEPER-3598
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3598
> Project: ZooKeeper
>  Issue Type: Bug
>  Components: server
>Affects Versions: 3.6.0
>Reporter: Fangmin Lv
>Assignee: Fangmin Lv
>Priority: Critical
>  Labels: pull-request-available
> Fix For: 3.6.0
>
>  Time Spent: 1h 10m
>  Remaining Estimate: 0h
>
>  
> There was a regression introduced after inline the write in CommitProcessor 
> with changes intorduced in ZOOKEEPER-3359, which didn't wait the in-flight 
> write to finish before calling shutdown on the nextProcessor.
>  
> So it's possible that CommitProcessor thread and QuorumPeer thread will 
> update the DataTree concurrently if we're doing fastForwardDataBase at the 
> end of ZooKeeperServer.shutdown, which will cause inconsistent issue.
>  
> This JIRA is going to make sure we wait on the CommitProcessor to shutdown 
> gracefully before calling shutdown on next processor, and exit if we cannot 
> finish it gracefully to avoid potential inconsistency.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (ZOOKEEPER-3363) Drop ant basedbuild umbrella issue

2019-11-11 Thread ASF GitHub Bot (Jira)


 [ 
https://issues.apache.org/jira/browse/ZOOKEEPER-3363?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

ASF GitHub Bot updated ZOOKEEPER-3363:
--
Labels: pull-request-available  (was: )

> Drop ant basedbuild umbrella issue
> --
>
> Key: ZOOKEEPER-3363
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3363
> Project: ZooKeeper
>  Issue Type: Task
>  Components: build
>Reporter: Enrico Olivelli
>Assignee: Enrico Olivelli
>Priority: Major
>  Labels: pull-request-available
> Fix For: 3.6.0
>
>
> This is an umbrella issue to track activites related to dropping ant based 
> build now that we have (since 3.5.5) Maven fully working.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Created] (ZOOKEEPER-3611) strengthen CLI:addWatch to support all watch event type and add a documentation

2019-11-11 Thread maoling (Jira)
maoling created ZOOKEEPER-3611:
--

 Summary: strengthen CLI:addWatch to support all watch event type 
and add a documentation
 Key: ZOOKEEPER-3611
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3611
 Project: ZooKeeper
  Issue Type: Improvement
Reporter: maoling
Assignee: maoling






--
This message was sent by Atlassian Jira
(v8.3.4#803005)