[GitHub] zookeeper pull request #567: ZOOKEEPER-3071: Add a config parameter to contr...
Github user suyogmapara commented on a diff in the pull request: https://github.com/apache/zookeeper/pull/567#discussion_r206338732 --- Diff: src/java/main/org/apache/zookeeper/server/persistence/FileTxnLog.java --- @@ -102,6 +102,21 @@ /** Maximum time we allow for elapsed fsync before WARNing */ private final static long fsyncWarningThresholdMS; +/** + * This parameter limit the size of each txnlog to a given limit (KB). + * It does not affect how often the system will take a snapshot [zookeeper.snapCount] + * We roll the txnlog when either of the two limits are reached. + * Also since we only roll the logs at transaction boundaries, actual file size can exceed + * this limit by the maximum size of a serialized transaction. + * The feature is disabled by default (-1) + */ +public static final String LOG_SIZE_LIMIT = "zookeeper.txnlogSizeLimitInKb"; --- End diff -- Thanks @anmolnar I will update the patch soon with documentation. ---
[jira] [Created] (ZOOKEEPER-3107) Coding standard and Checkstyle
Praveendra Singh created ZOOKEEPER-3107: --- Summary: Coding standard and Checkstyle Key: ZOOKEEPER-3107 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3107 Project: ZooKeeper Issue Type: Improvement Components: build Reporter: Praveendra Singh I'm new to the Zookeeper as a contributor. Was going through [https://cwiki.apache.org/confluence/display/ZOOKEEPER/HowToContribute] a and noticed that link to [Sun's conventions|http://www.oracle.com/technetwork/java/codeconv-138413.html] doesn't work. Did some googling and noticed that it is archived at [https://www.oracle.com/technetwork/java/javase/overview/codeconvtoc-136057.html]. Do we still use this coding standard? Apart from the code styling rules, we have additional ones listed on the Contributor Guide. Instead of letting everyone remember all the rules, should we force it at build time? There is a [Maven Checkstyle Plugin|https://maven.apache.org/plugins/maven-checkstyle-plugin/] which can be leveraged. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] zookeeper issue #545: ZOOKEEPER-2261 When only secureClientPort is configure...
Github user hanm commented on the issue: https://github.com/apache/zookeeper/pull/545 >> We could keep the original API and setting the secure field appropriate to stay on the safe side, but that won't satisfy your suggestion. I think we can do this. Later when we can break compatibility, we can remove the redundant API. I don't want to block this patch because of this - it can be done as a separate JIRA. ---
[jira] [Commented] (ZOOKEEPER-1621) ZooKeeper does not recover from crash when disk was full
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1621?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16562446#comment-16562446 ] Hadoop QA commented on ZOOKEEPER-1621: -- -1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12837140/ZOOKEEPER-1621.2.patch against trunk revision 78e4a1047c701006dd4ec8d09065eda0e7adedb5. +1 @author. The patch does not contain any @author tags. +1 tests included. The patch appears to include 3 new or modified tests. -1 patch. The patch command could not apply the patch. Console output: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/3700//console This message is automatically generated. > ZooKeeper does not recover from crash when disk was full > > > Key: ZOOKEEPER-1621 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1621 > Project: ZooKeeper > Issue Type: Bug > Components: server >Affects Versions: 3.4.3 > Environment: Ubuntu 12.04, Amazon EC2 instance >Reporter: David Arthur >Assignee: Michi Mutsuzaki >Priority: Major > Labels: pull-request-available > Fix For: 3.6.0, 3.5.5 > > Attachments: ZOOKEEPER-1621.2.patch, ZOOKEEPER-1621.patch, > zookeeper.log.gz > > Time Spent: 10m > Remaining Estimate: 0h > > The disk that ZooKeeper was using filled up. During a snapshot write, I got > the following exception > 2013-01-16 03:11:14,098 - ERROR [SyncThread:0:SyncRequestProcessor@151] - > Severe unrecoverable error, exiting > java.io.IOException: No space left on device > at java.io.FileOutputStream.writeBytes(Native Method) > at java.io.FileOutputStream.write(FileOutputStream.java:282) > at > java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:65) > at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:123) > at > org.apache.zookeeper.server.persistence.FileTxnLog.commit(FileTxnLog.java:309) > at > org.apache.zookeeper.server.persistence.FileTxnSnapLog.commit(FileTxnSnapLog.java:306) > at org.apache.zookeeper.server.ZKDatabase.commit(ZKDatabase.java:484) > at > org.apache.zookeeper.server.SyncRequestProcessor.flush(SyncRequestProcessor.java:162) > at > org.apache.zookeeper.server.SyncRequestProcessor.run(SyncRequestProcessor.java:101) > Then many subsequent exceptions like: > 2013-01-16 15:02:23,984 - ERROR [main:Util@239] - Last transaction was > partial. > 2013-01-16 15:02:23,985 - ERROR [main:ZooKeeperServerMain@63] - Unexpected > exception, exiting abnormally > java.io.EOFException > at java.io.DataInputStream.readInt(DataInputStream.java:375) > at > org.apache.jute.BinaryInputArchive.readInt(BinaryInputArchive.java:63) > at > org.apache.zookeeper.server.persistence.FileHeader.deserialize(FileHeader.java:64) > at > org.apache.zookeeper.server.persistence.FileTxnLog$FileTxnIterator.inStreamCreated(FileTxnLog.java:558) > at > org.apache.zookeeper.server.persistence.FileTxnLog$FileTxnIterator.createInputArchive(FileTxnLog.java:577) > at > org.apache.zookeeper.server.persistence.FileTxnLog$FileTxnIterator.goToNextLog(FileTxnLog.java:543) > at > org.apache.zookeeper.server.persistence.FileTxnLog$FileTxnIterator.next(FileTxnLog.java:625) > at > org.apache.zookeeper.server.persistence.FileTxnLog$FileTxnIterator.init(FileTxnLog.java:529) > at > org.apache.zookeeper.server.persistence.FileTxnLog$FileTxnIterator.(FileTxnLog.java:504) > at > org.apache.zookeeper.server.persistence.FileTxnLog.read(FileTxnLog.java:341) > at > org.apache.zookeeper.server.persistence.FileTxnSnapLog.restore(FileTxnSnapLog.java:130) > at > org.apache.zookeeper.server.ZKDatabase.loadDataBase(ZKDatabase.java:223) > at > org.apache.zookeeper.server.ZooKeeperServer.loadData(ZooKeeperServer.java:259) > at > org.apache.zookeeper.server.ZooKeeperServer.startdata(ZooKeeperServer.java:386) > at > org.apache.zookeeper.server.NIOServerCnxnFactory.startup(NIOServerCnxnFactory.java:138) > at > org.apache.zookeeper.server.ZooKeeperServerMain.runFromConfig(ZooKeeperServerMain.java:112) > at > org.apache.zookeeper.server.ZooKeeperServerMain.initializeAndRun(ZooKeeperServerMain.java:86) > at > org.apache.zookeeper.server.ZooKeeperServerMain.main(ZooKeeperServerMain.java:52) > at > org.apache.zookeeper.server.quorum.QuorumPeerMain.initializeAndRun(QuorumPeerMain.java:116) > at > org.apache.zookeeper.server.quorum.QuorumPeerMain.main(QuorumPeerMain.java:78) > It seems to me that writing the transaction log should be fully atomic to > avoid such situations. Is this not
Failed: ZOOKEEPER-1621 PreCommit Build #3700
Jira: https://issues.apache.org/jira/browse/ZOOKEEPER-1621 Build: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/3700/ ### ## LAST 60 LINES OF THE CONSOLE ### [...truncated 6.62 KB...] [exec] [exec] [exec] [exec] -1 overall. Here are the results of testing the latest attachment [exec] http://issues.apache.org/jira/secure/attachment/12837140/ZOOKEEPER-1621.2.patch [exec] against trunk revision 78e4a1047c701006dd4ec8d09065eda0e7adedb5. [exec] [exec] +1 @author. The patch does not contain any @author tags. [exec] [exec] +1 tests included. The patch appears to include 3 new or modified tests. [exec] [exec] -1 patch. The patch command could not apply the patch. [exec] [exec] Console output: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/3700//console [exec] [exec] This message is automatically generated. [exec] [exec] [exec] == [exec] == [exec] Adding comment to Jira. [exec] == [exec] == [exec] [exec] [exec] Comment with id 16562446 added to ZOOKEEPER-1621. [exec] Session logged out. Session was JSESSIONID=299410C9FF36C63B0518E6B650A4C518. [exec] [exec] [exec] == [exec] == [exec] Finished build. [exec] == [exec] == [exec] [exec] [exec] mv: '/home/jenkins/jenkins-slave/workspace/PreCommit-ZOOKEEPER-Build/patchprocess' and '/home/jenkins/jenkins-slave/workspace/PreCommit-ZOOKEEPER-Build/patchprocess' are the same file BUILD FAILED /home/jenkins/jenkins-slave/workspace/PreCommit-ZOOKEEPER-Build/build.xml:1785: exec returned: 1 Total time: 47 seconds Build step 'Execute shell' marked build as failure Archiving artifacts Setting JDK_1_8_LATEST__HOME=/home/jenkins/tools/java/latest1.8 [Fast Archiver] No prior successful build to compare, so performing full copy of artifacts Recording test results Setting JDK_1_8_LATEST__HOME=/home/jenkins/tools/java/latest1.8 ERROR: Step ?Publish JUnit test result report? failed: No test report files were found. Configuration error? Setting JDK_1_8_LATEST__HOME=/home/jenkins/tools/java/latest1.8 [description-setter] Description set: ZOOKEEPER-3082 Setting JDK_1_8_LATEST__HOME=/home/jenkins/tools/java/latest1.8 Setting JDK_1_8_LATEST__HOME=/home/jenkins/tools/java/latest1.8 Email was triggered for: Failure - Any Sending email for trigger: Failure - Any Setting JDK_1_8_LATEST__HOME=/home/jenkins/tools/java/latest1.8 Setting JDK_1_8_LATEST__HOME=/home/jenkins/tools/java/latest1.8 Setting JDK_1_8_LATEST__HOME=/home/jenkins/tools/java/latest1.8 Setting JDK_1_8_LATEST__HOME=/home/jenkins/tools/java/latest1.8 ### ## FAILED TESTS (if any) ## No tests ran.
[jira] [Updated] (ZOOKEEPER-1621) ZooKeeper does not recover from crash when disk was full
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated ZOOKEEPER-1621: -- Labels: pull-request-available (was: ) > ZooKeeper does not recover from crash when disk was full > > > Key: ZOOKEEPER-1621 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1621 > Project: ZooKeeper > Issue Type: Bug > Components: server >Affects Versions: 3.4.3 > Environment: Ubuntu 12.04, Amazon EC2 instance >Reporter: David Arthur >Assignee: Michi Mutsuzaki >Priority: Major > Labels: pull-request-available > Fix For: 3.6.0, 3.5.5 > > Attachments: ZOOKEEPER-1621.2.patch, ZOOKEEPER-1621.patch, > zookeeper.log.gz > > > The disk that ZooKeeper was using filled up. During a snapshot write, I got > the following exception > 2013-01-16 03:11:14,098 - ERROR [SyncThread:0:SyncRequestProcessor@151] - > Severe unrecoverable error, exiting > java.io.IOException: No space left on device > at java.io.FileOutputStream.writeBytes(Native Method) > at java.io.FileOutputStream.write(FileOutputStream.java:282) > at > java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:65) > at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:123) > at > org.apache.zookeeper.server.persistence.FileTxnLog.commit(FileTxnLog.java:309) > at > org.apache.zookeeper.server.persistence.FileTxnSnapLog.commit(FileTxnSnapLog.java:306) > at org.apache.zookeeper.server.ZKDatabase.commit(ZKDatabase.java:484) > at > org.apache.zookeeper.server.SyncRequestProcessor.flush(SyncRequestProcessor.java:162) > at > org.apache.zookeeper.server.SyncRequestProcessor.run(SyncRequestProcessor.java:101) > Then many subsequent exceptions like: > 2013-01-16 15:02:23,984 - ERROR [main:Util@239] - Last transaction was > partial. > 2013-01-16 15:02:23,985 - ERROR [main:ZooKeeperServerMain@63] - Unexpected > exception, exiting abnormally > java.io.EOFException > at java.io.DataInputStream.readInt(DataInputStream.java:375) > at > org.apache.jute.BinaryInputArchive.readInt(BinaryInputArchive.java:63) > at > org.apache.zookeeper.server.persistence.FileHeader.deserialize(FileHeader.java:64) > at > org.apache.zookeeper.server.persistence.FileTxnLog$FileTxnIterator.inStreamCreated(FileTxnLog.java:558) > at > org.apache.zookeeper.server.persistence.FileTxnLog$FileTxnIterator.createInputArchive(FileTxnLog.java:577) > at > org.apache.zookeeper.server.persistence.FileTxnLog$FileTxnIterator.goToNextLog(FileTxnLog.java:543) > at > org.apache.zookeeper.server.persistence.FileTxnLog$FileTxnIterator.next(FileTxnLog.java:625) > at > org.apache.zookeeper.server.persistence.FileTxnLog$FileTxnIterator.init(FileTxnLog.java:529) > at > org.apache.zookeeper.server.persistence.FileTxnLog$FileTxnIterator.(FileTxnLog.java:504) > at > org.apache.zookeeper.server.persistence.FileTxnLog.read(FileTxnLog.java:341) > at > org.apache.zookeeper.server.persistence.FileTxnSnapLog.restore(FileTxnSnapLog.java:130) > at > org.apache.zookeeper.server.ZKDatabase.loadDataBase(ZKDatabase.java:223) > at > org.apache.zookeeper.server.ZooKeeperServer.loadData(ZooKeeperServer.java:259) > at > org.apache.zookeeper.server.ZooKeeperServer.startdata(ZooKeeperServer.java:386) > at > org.apache.zookeeper.server.NIOServerCnxnFactory.startup(NIOServerCnxnFactory.java:138) > at > org.apache.zookeeper.server.ZooKeeperServerMain.runFromConfig(ZooKeeperServerMain.java:112) > at > org.apache.zookeeper.server.ZooKeeperServerMain.initializeAndRun(ZooKeeperServerMain.java:86) > at > org.apache.zookeeper.server.ZooKeeperServerMain.main(ZooKeeperServerMain.java:52) > at > org.apache.zookeeper.server.quorum.QuorumPeerMain.initializeAndRun(QuorumPeerMain.java:116) > at > org.apache.zookeeper.server.quorum.QuorumPeerMain.main(QuorumPeerMain.java:78) > It seems to me that writing the transaction log should be fully atomic to > avoid such situations. Is this not the case? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] zookeeper issue #439: ZOOKEEPER-1621: Delete and skip txn log with incomplet...
Github user anmolnar commented on the issue: https://github.com/apache/zookeeper/pull/439 @abhishekrai @hanm Given that we closed #560 , is this pull request still relevant? Maybe I'm missing something here and these are just similar issues and not the same. ---
[jira] [Commented] (ZOOKEEPER-3082) Fix server snapshot behavior when out of disk space
[ https://issues.apache.org/jira/browse/ZOOKEEPER-3082?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16562430#comment-16562430 ] Andor Molnar commented on ZOOKEEPER-3082: - [~nixon] [~hanm] Thanks for sorting this out. Do you think it fixes ZOOKEEPER-1621? > Fix server snapshot behavior when out of disk space > --- > > Key: ZOOKEEPER-3082 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3082 > Project: ZooKeeper > Issue Type: Bug > Components: server >Affects Versions: 3.6.0, 3.4.12, 3.5.5 >Reporter: Brian Nixon >Assignee: Brian Nixon >Priority: Minor > Labels: pull-request-available > Fix For: 3.6.0 > > Time Spent: 1h 10m > Remaining Estimate: 0h > > When the ZK server tries to make a snapshot and the machine is out of disk > space, the snapshot creation fails and throws an IOException. An empty > snapshot file is created, (probably because the server is able to create an > entry in the dir) but is not able to write to the file. > > If snapshot creation fails, the server commits suicide. When it restarts, it > will do so from the last known good snapshot. However, when it tries to make > a snapshot again, the same thing happens. This results in lots of empty > snapshot files being created. If eventually the DataDirCleanupManager garbage > collects the good snapshot files then only the empty files remain. At this > point, the server is well and truly screwed. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] zookeeper issue #572: ZOOKEEPER-3085 define exit codes in enum
Github user pravsingh commented on the issue: https://github.com/apache/zookeeper/pull/572 agree with you guys. ð ---
[GitHub] zookeeper issue #572: ZOOKEEPER-3085 define exit codes in enum
Github user anmolnar commented on the issue: https://github.com/apache/zookeeper/pull/572 @pravsingh @nkalmar I don't think we need to add unit tests to verify enum values, it doesn't add too much value I believe. Unless we already have unit tests like this in the codebase, but I can't think of any. ---
[GitHub] zookeeper issue #545: ZOOKEEPER-2261 When only secureClientPort is configure...
Github user anmolnar commented on the issue: https://github.com/apache/zookeeper/pull/545 @hanm Trying to make the API consistent by keeping one setter and getter for the property. It escalated a bunch of other changes which I think are good improvements and made the code simpler: e.g. removed checks for secure/non-secure ServerCnxnFactory, because now we only have one. But. It introduced an API change (no separate setter for the secure case and signature has been changed for the non-secure). This might be a problem for dependent projects like Curator which already takes advantage of 3.5 version. We could keep the original API and setting the `secure` field appropriate to stay on the safe side, but that won't satisfy your suggestion. ---
[GitHub] zookeeper issue #572: ZOOKEEPER-3085 define exit codes in enum
Github user nkalmar commented on the issue: https://github.com/apache/zookeeper/pull/572 @pravsingh , I changed the comments to javadoc comments. But after creating the tests, it was kind of strange. I looked at other enum in ZK, we don't check the values. I think we will see in a PR if someone wants to change the enum's value. (And if someone wants to change it, he might as easily change the tests too). Bottom line, I don't think it is necessary to have a unit test to check ExitCode values. What do others think? ---
[jira] [Commented] (ZOOKEEPER-3036) Unexpected exception in zookeeper
[ https://issues.apache.org/jira/browse/ZOOKEEPER-3036?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16561968#comment-16561968 ] Benjamin Reed commented on ZOOKEEPER-3036: -- can you give a bit more detail as to what happened? there were 3 servers. it sounds like one of the followers failed right? the leader should keep working with the other follower alive. did the leader actually shutdown as well? > Unexpected exception in zookeeper > - > > Key: ZOOKEEPER-3036 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3036 > Project: ZooKeeper > Issue Type: Bug > Components: quorum, server >Affects Versions: 3.4.10 > Environment: 3 Zookeepers, 5 kafka servers >Reporter: Oded >Priority: Critical > > We got an issue with one of the zookeeprs (Leader), causing the entire kafka > cluster to fail: > 2018-05-09 02:29:01,730 [myid:3] - ERROR > [LearnerHandler-/192.168.0.91:42490:LearnerHandler@648] - Unexpected > exception causing shutdown while sock still open > java.net.SocketTimeoutException: Read timed out > at java.net.SocketInputStream.socketRead0(Native Method) > at java.net.SocketInputStream.socketRead(SocketInputStream.java:116) > at java.net.SocketInputStream.read(SocketInputStream.java:171) > at java.net.SocketInputStream.read(SocketInputStream.java:141) > at java.io.BufferedInputStream.fill(BufferedInputStream.java:246) > at java.io.BufferedInputStream.read(BufferedInputStream.java:265) > at java.io.DataInputStream.readInt(DataInputStream.java:387) > at > org.apache.jute.BinaryInputArchive.readInt(BinaryInputArchive.java:63) > at > org.apache.zookeeper.server.quorum.QuorumPacket.deserialize(QuorumPacket.java:83) > at > org.apache.jute.BinaryInputArchive.readRecord(BinaryInputArchive.java:99) > at > org.apache.zookeeper.server.quorum.LearnerHandler.run(LearnerHandler.java:559) > 2018-05-09 02:29:01,730 [myid:3] - WARN > [LearnerHandler-/192.168.0.91:42490:LearnerHandler@661] - *** GOODBYE > /192.168.0.91:42490 > > We would expect that zookeeper will choose another Leader and the Kafka > cluster will continue to work as expected, but that was not the case. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (ZOOKEEPER-3106) Zookeeper client supports IPv6 address and document the "IPV6 feature"
[ https://issues.apache.org/jira/browse/ZOOKEEPER-3106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] ASF GitHub Bot updated ZOOKEEPER-3106: -- Labels: pull-request-available (was: ) > Zookeeper client supports IPv6 address and document the "IPV6 feature" > -- > > Key: ZOOKEEPER-3106 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3106 > Project: ZooKeeper > Issue Type: Improvement > Components: documentation, java client >Reporter: maoling >Assignee: maoling >Priority: Major > Labels: pull-request-available > > This issue is the follow-up work of > [ZOOKEEPER-3057|https://issues.apache.org/jira/browse/ZOOKEEPER-3057] > 1.ZK server side supports ipv6 style like this: > server.1=[2001:db8:1::242:ac11:2]:2888:3888,but zk client side supports ipv6 > like this:2001:db8:1::242:ac11:2:2181.we need unify them. > Look at the kafka example > [KAFKA-1123|https://issues.apache.org/jira/browse/KAFKA-1123]. its producer > client also supports ipv6 like this: [2001:db8:1::242:ac11:2] > 2.document the "IPV6 feature" to let user know. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] zookeeper pull request #587: ZOOKEEPER-3106: Zookeeper client supports IPv6 ...
GitHub user maoling opened a pull request: https://github.com/apache/zookeeper/pull/587 ZOOKEEPER-3106: Zookeeper client supports IPv6 address and document the "IPV6 feature" The related UTs in the `ConnectStringParserTest` have all passed,I also tested it in the real IPv6 ENV. More details in [ZOOKEEPER-3106](https://issues.apache.org/jira/browse/ZOOKEEPER-3106) You can merge this pull request into a Git repository by running: $ git pull https://github.com/maoling/zookeeper ZOOKEEPER-3106 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/zookeeper/pull/587.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #587 commit 6942315d8fc66200a55691df9a59eadf13ff0270 Author: maoling Date: 2018-07-29T08:42:10Z ZOOKEEPER-3106: Zookeeper client supports IPv6 address and document the IPV6 feature ---
[GitHub] zookeeper pull request #545: ZOOKEEPER-2261 When only secureClientPort is co...
Github user anmolnar commented on a diff in the pull request:
https://github.com/apache/zookeeper/pull/545#discussion_r206120103
--- Diff: src/java/main/org/apache/zookeeper/server/ZooKeeperServer.java ---
@@ -866,6 +866,9 @@ public void setServerCnxnFactory(ServerCnxnFactory
factory) {
}
public ServerCnxnFactory getServerCnxnFactory() {
+if (secureServerCnxnFactory != null) {
+return secureServerCnxnFactory;
+}
return serverCnxnFactory;
}
--- End diff --
Makes sense.
---
[GitHub] zookeeper pull request #:
Github user anmolnar commented on the pull request: https://github.com/apache/zookeeper/commit/a2623a625a4778720f7d5482d0a66e9b37ae556f#commitcomment-29886282 Insecure. JMX and Jetty are the future for 3.5+ JMX is also questionable. Not sure if we could drop that too. ---
[GitHub] zookeeper pull request #:
Github user maoling commented on the pull request: https://github.com/apache/zookeeper/commit/a2623a625a4778720f7d5482d0a66e9b37ae556f#commitcomment-29885683 @nkalmar Thanks for your ACK. 4 letter words will be deprecated? why? ---
ZooKeeper_branch35_jdk8 - Build # 1065 - Failure
See https://builds.apache.org/job/ZooKeeper_branch35_jdk8/1065/ ### ## LAST 60 LINES OF THE CONSOLE ### [...truncated 62.76 KB...] [junit] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.113 sec, Thread: 3, Class: org.apache.zookeeper.test.SaslClientTest [junit] Running org.apache.zookeeper.test.ServerCnxnTest in thread 1 [junit] Running org.apache.zookeeper.test.SaslSuperUserTest in thread 6 [junit] Running org.apache.zookeeper.test.SessionInvalidationTest in thread 3 [junit] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.104 sec, Thread: 6, Class: org.apache.zookeeper.test.SaslSuperUserTest [junit] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.762 sec, Thread: 3, Class: org.apache.zookeeper.test.SessionInvalidationTest [junit] Running org.apache.zookeeper.test.SessionTest in thread 6 [junit] Running org.apache.zookeeper.test.SessionTimeoutTest in thread 3 [junit] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 3.584 sec, Thread: 1, Class: org.apache.zookeeper.test.ServerCnxnTest [junit] Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.502 sec, Thread: 3, Class: org.apache.zookeeper.test.SessionTimeoutTest [junit] Running org.apache.zookeeper.test.SessionTrackerCheckTest in thread 1 [junit] Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.084 sec, Thread: 1, Class: org.apache.zookeeper.test.SessionTrackerCheckTest [junit] Running org.apache.zookeeper.test.SessionUpgradeTest in thread 3 [junit] Running org.apache.zookeeper.test.StandaloneTest in thread 1 [junit] Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 2.951 sec, Thread: 1, Class: org.apache.zookeeper.test.StandaloneTest [junit] Running org.apache.zookeeper.test.StatTest in thread 1 [junit] Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.304 sec, Thread: 1, Class: org.apache.zookeeper.test.StatTest [junit] Running org.apache.zookeeper.test.StaticHostProviderTest in thread 1 [junit] Tests run: 26, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.731 sec, Thread: 1, Class: org.apache.zookeeper.test.StaticHostProviderTest [junit] Running org.apache.zookeeper.test.StringUtilTest in thread 1 [junit] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.082 sec, Thread: 1, Class: org.apache.zookeeper.test.StringUtilTest [junit] Running org.apache.zookeeper.test.SyncCallTest in thread 1 [junit] Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 12.625 sec, Thread: 6, Class: org.apache.zookeeper.test.SessionTest [junit] Running org.apache.zookeeper.test.TruncateTest in thread 6 [junit] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.954 sec, Thread: 1, Class: org.apache.zookeeper.test.SyncCallTest [junit] Running org.apache.zookeeper.test.WatchEventWhenAutoResetTest in thread 1 [junit] Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 72.732 sec, Thread: 5, Class: org.apache.zookeeper.test.QuorumZxidSyncTest [junit] Running org.apache.zookeeper.test.WatchedEventTest in thread 5 [junit] Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.066 sec, Thread: 5, Class: org.apache.zookeeper.test.WatchedEventTest [junit] Running org.apache.zookeeper.test.WatcherFuncTest in thread 5 [junit] Tests run: 14, Failures: 0, Errors: 0, Skipped: 1, Time elapsed: 89.616 sec, Thread: 4, Class: org.apache.zookeeper.test.QuorumTest [junit] Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 6.654 sec, Thread: 6, Class: org.apache.zookeeper.test.TruncateTest [junit] Running org.apache.zookeeper.test.WatcherTest in thread 6 [junit] Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 2.379 sec, Thread: 5, Class: org.apache.zookeeper.test.WatcherFuncTest [junit] Running org.apache.zookeeper.test.X509AuthTest in thread 4 [junit] Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.102 sec, Thread: 4, Class: org.apache.zookeeper.test.X509AuthTest [junit] Running org.apache.zookeeper.test.ZkDatabaseCorruptionTest in thread 5 [junit] Running org.apache.zookeeper.test.ZooKeeperQuotaTest in thread 4 [junit] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.93 sec, Thread: 4, Class: org.apache.zookeeper.test.ZooKeeperQuotaTest [junit] Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 23.634 sec, Thread: 3, Class: org.apache.zookeeper.test.SessionUpgradeTest [junit] Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 10.809 sec, Thread: 5, Class: org.apache.zookeeper.test.ZkDatabaseCorruptionTest [junit] Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 23.948 sec,
[GitHub] zookeeper pull request #572: ZOOKEEPER-3085 define exit codes in enum
Github user nkalmar commented on a diff in the pull request:
https://github.com/apache/zookeeper/pull/572#discussion_r206045238
--- Diff: src/java/main/org/apache/zookeeper/server/ExitCode.java ---
@@ -20,8 +20,35 @@
/**
* Exit code used to exit server
*/
-public class ExitCode {
+public enum ExitCode {
+
+/* Execution finished normally */
+EXECUTION_FINISHED(0),
+/* Unexpected errors like IO Exceptions */
+UNEXPECTED_ERROR(1),
+/* Invalid arguments during invocations */
+INVALID_INVOCATION(2),
+/* Cannot access datadir when trying to replicate server */
+UNABLE_TO_ACCESS_DATADIR(3),
+/* Unable to start admin server at ZooKeeper startup */
+ERROR_STARTING_ADMIN_SERVER(4),
+/* Severe error during snapshot IO */
+TXNLOG_ERROR_TAKING_SNAPSHOT(10),
+/* zxid from COMMIT does not match the one from pendingTxns queue */
+UNMATCHED_TXN_COMMIT(12),
+/* Unexpected packet from leader, or unable to truncate log on
Leader.TRUNC */
+QUORUM_PACKET_ERROR(13),
+/* Unable to bind to the quorum (election) port after multiple retry */
+UNABLE_TO_BIND_QUORUM_PORT(14);
+
+private final int value;
+
+ExitCode(final int newValue) {
+value = newValue;
+}
+
+public int getValue() {
--- End diff --
No, I will write them. Thanks!
---
[GitHub] zookeeper pull request #:
Github user nkalmar commented on the pull request: https://github.com/apache/zookeeper/commit/a2623a625a4778720f7d5482d0a66e9b37ae556f#commitcomment-29880817 @maoling It has been intentionally removed from 3.6 and 3.5, as I was told the 4 letter words is deprecated, and it will be removed. No new metrics should be introduced. ---
[jira] [Updated] (ZOOKEEPER-3106) Zookeeper client supports IPv6 address and document the "IPV6 feature"
[ https://issues.apache.org/jira/browse/ZOOKEEPER-3106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] maoling updated ZOOKEEPER-3106: --- Description: This issue is the follow-up work of [ZOOKEEPER-3057|https://issues.apache.org/jira/browse/ZOOKEEPER-3057] 1.ZK server side supports ipv6 style like this: server.1=[2001:db8:1::242:ac11:2]:2888:3888,but zk client side supports ipv6 like this:2001:db8:1::242:ac11:2:2181.we need unify them. Look at the kafka example [KAFKA-1123|https://issues.apache.org/jira/browse/KAFKA-1123]. its producer client also supports ipv6 like this: [2001:db8:1::242:ac11:2] 2.document the "IPV6 feature" to let user know. > Zookeeper client supports IPv6 address and document the "IPV6 feature" > -- > > Key: ZOOKEEPER-3106 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3106 > Project: ZooKeeper > Issue Type: Improvement > Components: documentation, java client >Reporter: maoling >Assignee: maoling >Priority: Major > > This issue is the follow-up work of > [ZOOKEEPER-3057|https://issues.apache.org/jira/browse/ZOOKEEPER-3057] > 1.ZK server side supports ipv6 style like this: > server.1=[2001:db8:1::242:ac11:2]:2888:3888,but zk client side supports ipv6 > like this:2001:db8:1::242:ac11:2:2181.we need unify them. > Look at the kafka example > [KAFKA-1123|https://issues.apache.org/jira/browse/KAFKA-1123]. its producer > client also supports ipv6 like this: [2001:db8:1::242:ac11:2] > 2.document the "IPV6 feature" to let user know. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ZOOKEEPER-3082) Fix server snapshot behavior when out of disk space
[ https://issues.apache.org/jira/browse/ZOOKEEPER-3082?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16561475#comment-16561475 ] Hudson commented on ZOOKEEPER-3082: --- SUCCESS: Integrated in Jenkins build ZooKeeper-trunk #128 (See [https://builds.apache.org/job/ZooKeeper-trunk/128/]) ZOOKEEPER-3082: Fix server snapshot behavior when out of disk space (hanm: rev 78e4a1047c701006dd4ec8d09065eda0e7adedb5) * (edit) src/java/main/org/apache/zookeeper/server/persistence/FileTxnSnapLog.java * (add) src/java/test/org/apache/zookeeper/server/persistence/EmptySnapshotTest.java > Fix server snapshot behavior when out of disk space > --- > > Key: ZOOKEEPER-3082 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3082 > Project: ZooKeeper > Issue Type: Bug > Components: server >Affects Versions: 3.6.0, 3.4.12, 3.5.5 >Reporter: Brian Nixon >Assignee: Brian Nixon >Priority: Minor > Labels: pull-request-available > Fix For: 3.6.0 > > Time Spent: 1h 10m > Remaining Estimate: 0h > > When the ZK server tries to make a snapshot and the machine is out of disk > space, the snapshot creation fails and throws an IOException. An empty > snapshot file is created, (probably because the server is able to create an > entry in the dir) but is not able to write to the file. > > If snapshot creation fails, the server commits suicide. When it restarts, it > will do so from the last known good snapshot. However, when it tries to make > a snapshot again, the same thing happens. This results in lots of empty > snapshot files being created. If eventually the DataDirCleanupManager garbage > collects the good snapshot files then only the empty files remain. At this > point, the server is well and truly screwed. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
