[jira] [Commented] (ZOOKEEPER-1783) Distinguish initial configuration from first established configuration
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13792382#comment-13792382 ] Hadoop QA commented on ZOOKEEPER-1783: -- -1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12607949/ZOOKEEPER-1783-ver2.patch against trunk revision 1531061. +1 @author. The patch does not contain any @author tags. +1 tests included. The patch appears to include 6 new or modified tests. +1 javadoc. The javadoc tool did not generate any warning messages. +1 javac. The applied patch does not increase the total number of javac compiler warnings. +1 findbugs. The patch does not introduce any new Findbugs (version 1.3.9) warnings. +1 release audit. The applied patch does not increase the total number of release audit warnings. -1 core tests. The patch failed core unit tests. +1 contrib tests. The patch passed contrib unit tests. Test results: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1678//testReport/ Findbugs warnings: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1678//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html Console output: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1678//console This message is automatically generated. > Distinguish initial configuration from first established configuration > -- > > Key: ZOOKEEPER-1783 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1783 > Project: ZooKeeper > Issue Type: Bug > Components: quorum, server >Affects Versions: 3.5.0 >Reporter: Alexander Shraer >Assignee: Alexander Shraer > Fix For: 3.5.0 > > Attachments: ZOOKEEPER-1783.patch, ZOOKEEPER-1783-ver1.patch, > ZOOKEEPER-1783-ver2.patch > > > We need a way to distinguish an initial config of a server and an initial > config of a running ensemble (before any reconfigs happen). Currently both > have version 0. > The version of a config increases with each reconfiguration, so the problem > is just with the initial config. -- This message was sent by Atlassian JIRA (v6.1#6144)
Failed: ZOOKEEPER-1783 PreCommit Build #1678
Jira: https://issues.apache.org/jira/browse/ZOOKEEPER-1783 Build: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1678/ ### ## LAST 60 LINES OF THE CONSOLE ### [...truncated 936032 lines...] [exec] [exec] [exec] [exec] -1 overall. Here are the results of testing the latest attachment [exec] http://issues.apache.org/jira/secure/attachment/12607949/ZOOKEEPER-1783-ver2.patch [exec] against trunk revision 1531061. [exec] [exec] +1 @author. The patch does not contain any @author tags. [exec] [exec] +1 tests included. The patch appears to include 6 new or modified tests. [exec] [exec] +1 javadoc. The javadoc tool did not generate any warning messages. [exec] [exec] +1 javac. The applied patch does not increase the total number of javac compiler warnings. [exec] [exec] +1 findbugs. The patch does not introduce any new Findbugs (version 1.3.9) warnings. [exec] [exec] +1 release audit. The applied patch does not increase the total number of release audit warnings. [exec] [exec] -1 core tests. The patch failed core unit tests. [exec] [exec] +1 contrib tests. The patch passed contrib unit tests. [exec] [exec] Test results: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1678//testReport/ [exec] Findbugs warnings: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1678//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html [exec] Console output: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1678//console [exec] [exec] This message is automatically generated. [exec] [exec] [exec] == [exec] == [exec] Adding comment to Jira. [exec] == [exec] == [exec] [exec] [exec] Comment added. [exec] 569cefa72c5832b78292fdc4645d03c31a7d919d logged out [exec] [exec] [exec] == [exec] == [exec] Finished build. [exec] == [exec] == [exec] [exec] BUILD FAILED /home/jenkins/jenkins-slave/workspace/PreCommit-ZOOKEEPER-Build/trunk/build.xml:1623: exec returned: 1 Total time: 42 minutes 39 seconds Build step 'Execute shell' marked build as failure Archiving artifacts Recording test results Description set: ZOOKEEPER-1783 Email was triggered for: Failure Sending email for trigger: Failure ### ## FAILED TESTS (if any) ## 1 tests failed. REGRESSION: org.apache.zookeeper.test.ReadOnlyModeTest.testSeekForRwServer Error Message: Timeout occurred. Please note the time in the report does not reflect the time until the timeout. Stack Trace: junit.framework.AssertionFailedError: Timeout occurred. Please note the time in the report does not reflect the time until the timeout.
[jira] [Updated] (ZOOKEEPER-1783) Distinguish initial configuration from first established configuration
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1783?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Shraer updated ZOOKEEPER-1783: Attachment: ZOOKEEPER-1783-ver2.patch > Distinguish initial configuration from first established configuration > -- > > Key: ZOOKEEPER-1783 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1783 > Project: ZooKeeper > Issue Type: Bug > Components: quorum, server >Affects Versions: 3.5.0 >Reporter: Alexander Shraer >Assignee: Alexander Shraer > Fix For: 3.5.0 > > Attachments: ZOOKEEPER-1783.patch, ZOOKEEPER-1783-ver1.patch, > ZOOKEEPER-1783-ver2.patch > > > We need a way to distinguish an initial config of a server and an initial > config of a running ensemble (before any reconfigs happen). Currently both > have version 0. > The version of a config increases with each reconfiguration, so the problem > is just with the initial config. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (ZOOKEEPER-442) need a way to remove watches that are no longer of interest
[ https://issues.apache.org/jira/browse/ZOOKEEPER-442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13792349#comment-13792349 ] Rakesh R commented on ZOOKEEPER-442: Yes, I'm following the current approach with few improvements. Before starting I just prepared doc to understand the background and the proposed apis. I'll try to upload the working patch in couple of days. > need a way to remove watches that are no longer of interest > --- > > Key: ZOOKEEPER-442 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-442 > Project: ZooKeeper > Issue Type: New Feature >Reporter: Benjamin Reed >Assignee: Daniel Gómez Ferro >Priority: Critical > Fix For: 3.5.0 > > Attachments: Remove Watch API.pdf, ZOOKEEPER-442.patch, > ZOOKEEPER-442.patch, ZOOKEEPER-442.patch, ZOOKEEPER-442.patch, > ZOOKEEPER-442.patch, ZOOKEEPER-442.patch, ZOOKEEPER-442.patch > > > currently the only way a watch cleared is to trigger it. we need a way to > enumerate the outstanding watch objects, find watch events the objects are > watching for, and remove interests in an event. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (ZOOKEEPER-1793) Zab1_0Test.testNormalObserverRun() is flaky
[
https://issues.apache.org/jira/browse/ZOOKEEPER-1793?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Shraer updated ZOOKEEPER-1793:
Component/s: quorum
> Zab1_0Test.testNormalObserverRun() is flaky
> ---
>
> Key: ZOOKEEPER-1793
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1793
> Project: ZooKeeper
> Issue Type: Bug
> Components: quorum, server, tests
>Reporter: Alexander Shraer
>
> not sure if this is due to a known issue or not.
> // check and make sure the change is persisted
> zkDb2 = new ZKDatabase(new FileTxnSnapLog(logDir, snapDir));
> lastZxid = zkDb2.loadDataBase();
> Assert.assertEquals("data2", new String(zkDb2.getData("/foo", stat, null)));
> this assert periodically (once every 3 runs of the test or so) fails saying
> that getData returns data1 and not data2.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (ZOOKEEPER-1793) Zab1_0Test.testNormalObserverRun() is flaky
[
https://issues.apache.org/jira/browse/ZOOKEEPER-1793?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Shraer updated ZOOKEEPER-1793:
Component/s: server
> Zab1_0Test.testNormalObserverRun() is flaky
> ---
>
> Key: ZOOKEEPER-1793
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1793
> Project: ZooKeeper
> Issue Type: Bug
> Components: quorum, server, tests
>Reporter: Alexander Shraer
>
> not sure if this is due to a known issue or not.
> // check and make sure the change is persisted
> zkDb2 = new ZKDatabase(new FileTxnSnapLog(logDir, snapDir));
> lastZxid = zkDb2.loadDataBase();
> Assert.assertEquals("data2", new String(zkDb2.getData("/foo", stat, null)));
> this assert periodically (once every 3 runs of the test or so) fails saying
> that getData returns data1 and not data2.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Created] (ZOOKEEPER-1793) Zab1_0Test.testNormalObserverRun() is flaky
Alexander Shraer created ZOOKEEPER-1793:
---
Summary: Zab1_0Test.testNormalObserverRun() is flaky
Key: ZOOKEEPER-1793
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1793
Project: ZooKeeper
Issue Type: Bug
Components: tests
Reporter: Alexander Shraer
not sure if this is due to a known issue or not.
// check and make sure the change is persisted
zkDb2 = new ZKDatabase(new FileTxnSnapLog(logDir, snapDir));
lastZxid = zkDb2.loadDataBase();
Assert.assertEquals("data2", new String(zkDb2.getData("/foo", stat, null)));
this assert periodically (once every 3 runs of the test or so) fails saying
that getData returns data1 and not data2.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Created] (ZOOKEEPER-1793) Zab1_0Test.testNormalObserverRun() is flaky
Alexander Shraer created ZOOKEEPER-1793:
---
Summary: Zab1_0Test.testNormalObserverRun() is flaky
Key: ZOOKEEPER-1793
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1793
Project: ZooKeeper
Issue Type: Bug
Components: tests
Reporter: Alexander Shraer
not sure if this is due to a known issue or not.
// check and make sure the change is persisted
zkDb2 = new ZKDatabase(new FileTxnSnapLog(logDir, snapDir));
lastZxid = zkDb2.loadDataBase();
Assert.assertEquals("data2", new String(zkDb2.getData("/foo", stat, null)));
this assert periodically (once every 3 runs of the test or so) fails saying
that getData returns data1 and not data2.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Created] (ZOOKEEPER-1792) Observers don't need to keep the an in-memory copy of last commited proposals
Raul Gutierrez Segales created ZOOKEEPER-1792:
-
Summary: Observers don't need to keep the an in-memory copy of
last commited proposals
Key: ZOOKEEPER-1792
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1792
Project: ZooKeeper
Issue Type: Improvement
Reporter: Raul Gutierrez Segales
Priority: Minor
In FinalRequestProcessor.java#processRequest we have:
{noformat}
if (request.isQuorum()) {
zks.getZKDatabase().addCommittedProposal(request);
}
{noformat}
but this is only useful to the leader since committed proposals are only used
from LearnerHandler to sync up followers. I presume followers do need it as
they might become a leader at any point. But observers have no need for them,
so we could probably special case this for them and optimize the path for them.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (ZOOKEEPER-1768) Cluster fails election loop until the device is full
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13792189#comment-13792189 ] yuxin.yan commented on ZOOKEEPER-1768: -- Flavio Junqueira, after you read that, can you give me some advices for this situation, what should i do after the node is dead? thanks :) > Cluster fails election loop until the device is full > > > Key: ZOOKEEPER-1768 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1768 > Project: ZooKeeper > Issue Type: Bug > Components: leaderElection >Affects Versions: 3.4.5 >Reporter: yuxin.yan > Fix For: 3.4.6, 3.5.0 > > Attachments: zk_debug.log.2013-09-25.log, zoo.cfg > > > Hi, > I have a five nodes cluster versioned 3.4.5 and now i find one node is > offline. > Firstly i restart the node but i find that "Error contacting service. It is > probably not running." and i find that the node always elect the leader and > always sync the snapshot logs and the device will be full every ten mins. > so could someone help me？ i will put the log and zoo.cfg in the attachment. > Thanks all. > yyx, -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (ZOOKEEPER-1660) Add documentation for dynamic reconfiguration
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1660?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13792186#comment-13792186 ] Alexander Shraer commented on ZOOKEEPER-1660: - I can update the admin guide, and it does contain some important info for upgrade. But it may be better to do it right before the 3.5.0 release, so that for now we have a copy in Docs that everyone can easily read and we can edit. > Add documentation for dynamic reconfiguration > - > > Key: ZOOKEEPER-1660 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1660 > Project: ZooKeeper > Issue Type: Improvement > Components: documentation >Affects Versions: 3.5.0 >Reporter: Alexander Shraer >Assignee: Alexander Shraer > Fix For: 3.5.0 > > > Update user manual with reconfiguration info. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (ZOOKEEPER-1768) Cluster fails election loop until the device is full
[
https://issues.apache.org/jira/browse/ZOOKEEPER-1768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13792184#comment-13792184
]
yuxin.yan commented on ZOOKEEPER-1768:
--
Flavio Junqueira, thank you for your explanation. I agree with you. Here is the
detail after the node was dead: firstly, i found the disk is full the next
day(is it important for my case?), then i just restarted the node, then i found
that couse of "
autopurge.snapRetainCount=10
autopurge.purgeInterval=24
" configuration in the zoo.cfg, the node removed the other snapshots and
transaction logs, then it started failure("Error contacting service. It is
probably not running."), means it always wanted to sync to leader and recreate
new snapshots, then the disk was full again.
> Cluster fails election loop until the device is full
>
>
> Key: ZOOKEEPER-1768
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1768
> Project: ZooKeeper
> Issue Type: Bug
> Components: leaderElection
>Affects Versions: 3.4.5
>Reporter: yuxin.yan
> Fix For: 3.4.6, 3.5.0
>
> Attachments: zk_debug.log.2013-09-25.log, zoo.cfg
>
>
> Hi,
> I have a five nodes cluster versioned 3.4.5 and now i find one node is
> offline.
> Firstly i restart the node but i find that "Error contacting service. It is
> probably not running." and i find that the node always elect the leader and
> always sync the snapshot logs and the device will be full every ten mins.
> so could someone help me？ i will put the log and zoo.cfg in the attachment.
> Thanks all.
> yyx,
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (ZOOKEEPER-1660) Add documentation for dynamic reconfiguration
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1660?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13792175#comment-13792175 ] Patrick Hunt commented on ZOOKEEPER-1660: - [~shralex] what's the plan, you're going to update the admin guide for this? Release notes for upgrade necessary? > Add documentation for dynamic reconfiguration > - > > Key: ZOOKEEPER-1660 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1660 > Project: ZooKeeper > Issue Type: Improvement > Components: documentation >Affects Versions: 3.5.0 >Reporter: Alexander Shraer >Assignee: Alexander Shraer > Fix For: 3.5.0 > > > Update user manual with reconfiguration info. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (ZOOKEEPER-1650) testServerCnxnExpiry failing consistently on solaris apache jenkins
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1650?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Hunt updated ZOOKEEPER-1650: Priority: Blocker (was: Major) > testServerCnxnExpiry failing consistently on solaris apache jenkins > --- > > Key: ZOOKEEPER-1650 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1650 > Project: ZooKeeper > Issue Type: Bug > Components: tests >Affects Versions: 3.5.0 >Reporter: Patrick Hunt >Priority: Blocker > Fix For: 3.5.0 > > > testServerCnxnExpiry is failing consistently on solaris apache jenkins: > https://builds.apache.org/view/S-Z/view/ZooKeeper/job/ZooKeeper-trunk-solaris/475/testReport/org.apache.zookeeper.test/ServerCnxnTest/testServerCnxnExpiry/ > Seems to have started around the time the NIO multi-threading changes were > introduced - but it's hard to say (some of the history has been lost already). > Possibly just a bad test or timeouts not long enough... -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (ZOOKEEPER-1650) testServerCnxnExpiry failing consistently on solaris apache jenkins
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13792150#comment-13792150 ] Patrick Hunt commented on ZOOKEEPER-1650: - This is still failing consistently on solaris, nearly every failure here is due to this issue: https://builds.apache.org/view/S-Z/view/ZooKeeper/job/ZooKeeper-trunk-solaris/ > testServerCnxnExpiry failing consistently on solaris apache jenkins > --- > > Key: ZOOKEEPER-1650 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1650 > Project: ZooKeeper > Issue Type: Bug > Components: tests >Affects Versions: 3.5.0 >Reporter: Patrick Hunt >Priority: Blocker > Fix For: 3.5.0 > > > testServerCnxnExpiry is failing consistently on solaris apache jenkins: > https://builds.apache.org/view/S-Z/view/ZooKeeper/job/ZooKeeper-trunk-solaris/475/testReport/org.apache.zookeeper.test/ServerCnxnTest/testServerCnxnExpiry/ > Seems to have started around the time the NIO multi-threading changes were > introduced - but it's hard to say (some of the history has been lost already). > Possibly just a bad test or timeouts not long enough... -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (ZOOKEEPER-1633) Introduce a protocol version to connection initiation message
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13792141#comment-13792141 ] Raul Gutierrez Segales commented on ZOOKEEPER-1633: --- Now that I come to think of it, I might have seen it in prod. > Introduce a protocol version to connection initiation message > - > > Key: ZOOKEEPER-1633 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1633 > Project: ZooKeeper > Issue Type: Bug > Components: server >Reporter: Alexander Shraer >Assignee: Alexander Shraer > Fix For: 3.4.6 > > Attachments: ZOOKEEPER-1633.patch, ZOOKEEPER-1633-v4.patch, > ZOOKEEPER-1633-v4.patch, ZOOKEEPER-1633-ver2.patch, ZOOKEEPER-1633-ver3.patch > > > Currently the first message a server sends to another server includes just > one field - the server's id (long). This is in QuorumCnxManager.java. This > makes changes to the information passed during this initial connection very > difficult. This patch will change the first field of the message to be a > protocol version (a negative number that can't be a server id). The second > field will be the server id. The third field is number of bytes in the > remainder of the message. A 3.4 server will read the first field as before, > but if this is a negative number it will read the second field to find the > server id, and then remove the remainder of the message from the stream. This > will not affect 3.4 since 3.4 and earlier servers send just the server id (so > the code in the patch will not run unless there is a server > 3.4 trying to > connect). This will, however, provide the necessary flexibility for future > releases as well as an upgrade path from 3.4 -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (ZOOKEEPER-1791) ZooKeeper package includes unnecessary jars that are part of the package.
Mahadev konar created ZOOKEEPER-1791:
Summary: ZooKeeper package includes unnecessary jars that are part
of the package.
Key: ZOOKEEPER-1791
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1791
Project: ZooKeeper
Issue Type: Bug
Components: build
Affects Versions: 3.5.0
Reporter: Mahadev konar
Assignee: Mahadev konar
Fix For: 3.5.0
Attachments: ZOOKEEPER-1791.patch
ZooKeeper package includes unnecessary jars that are part of the package.
Packages like fatjar and
{code}
maven-ant-tasks-2.1.3.jar
maven-artifact-2.2.1.jar
maven-artifact-manager-2.2.1.jar
maven-error-diagnostics-2.2.1.jar
maven-model-2.2.1.jar
maven-plugin-registry-2.2.1.jar
maven-profile-2.2.1.jar
maven-project-2.2.1.jar
maven-repository-metadata-2.2.1.jar
{code}
are part of the zookeeper package and rpm (via bigtop).
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (ZOOKEEPER-1791) ZooKeeper package includes unnecessary jars that are part of the package.
[
https://issues.apache.org/jira/browse/ZOOKEEPER-1791?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mahadev konar updated ZOOKEEPER-1791:
-
Attachment: ZOOKEEPER-1791.patch
> ZooKeeper package includes unnecessary jars that are part of the package.
> -
>
> Key: ZOOKEEPER-1791
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1791
> Project: ZooKeeper
> Issue Type: Bug
> Components: build
>Affects Versions: 3.5.0
>Reporter: Mahadev konar
>Assignee: Mahadev konar
> Fix For: 3.5.0
>
> Attachments: ZOOKEEPER-1791.patch
>
>
> ZooKeeper package includes unnecessary jars that are part of the package.
> Packages like fatjar and
> {code}
> maven-ant-tasks-2.1.3.jar
> maven-artifact-2.2.1.jar
> maven-artifact-manager-2.2.1.jar
> maven-error-diagnostics-2.2.1.jar
> maven-model-2.2.1.jar
> maven-plugin-registry-2.2.1.jar
> maven-profile-2.2.1.jar
> maven-project-2.2.1.jar
> maven-repository-metadata-2.2.1.jar
> {code}
> are part of the zookeeper package and rpm (via bigtop).
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (ZOOKEEPER-1633) Introduce a protocol version to connection initiation message
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13792136#comment-13792136 ] Alexander Shraer commented on ZOOKEEPER-1633: - I'm not sure if ObserverId = -1 is actually something we need to support ? Is it used by anyone ? Perhaps someone can clarify [~breed] [~henryr] [~fpj] ? In any case, some of the reconfig functionality such as converting observers to followers is not supported for this kind of observers. > Introduce a protocol version to connection initiation message > - > > Key: ZOOKEEPER-1633 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1633 > Project: ZooKeeper > Issue Type: Bug > Components: server >Reporter: Alexander Shraer >Assignee: Alexander Shraer > Fix For: 3.4.6 > > Attachments: ZOOKEEPER-1633.patch, ZOOKEEPER-1633-v4.patch, > ZOOKEEPER-1633-v4.patch, ZOOKEEPER-1633-ver2.patch, ZOOKEEPER-1633-ver3.patch > > > Currently the first message a server sends to another server includes just > one field - the server's id (long). This is in QuorumCnxManager.java. This > makes changes to the information passed during this initial connection very > difficult. This patch will change the first field of the message to be a > protocol version (a negative number that can't be a server id). The second > field will be the server id. The third field is number of bytes in the > remainder of the message. A 3.4 server will read the first field as before, > but if this is a negative number it will read the second field to find the > server id, and then remove the remainder of the message from the stream. This > will not affect 3.4 since 3.4 and earlier servers send just the server id (so > the code in the patch will not run unless there is a server > 3.4 trying to > connect). This will, however, provide the necessary flexibility for future > releases as well as an upgrade path from 3.4 -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (ZOOKEEPER-1633) Introduce a protocol version to connection initiation message
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13792126#comment-13792126 ] Raul Gutierrez Segales commented on ZOOKEEPER-1633: --- Ah - never mind. Alex clarified this in ZOOKEEPER-1789. > Introduce a protocol version to connection initiation message > - > > Key: ZOOKEEPER-1633 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1633 > Project: ZooKeeper > Issue Type: Bug > Components: server >Reporter: Alexander Shraer >Assignee: Alexander Shraer > Fix For: 3.4.6 > > Attachments: ZOOKEEPER-1633.patch, ZOOKEEPER-1633-v4.patch, > ZOOKEEPER-1633-v4.patch, ZOOKEEPER-1633-ver2.patch, ZOOKEEPER-1633-ver3.patch > > > Currently the first message a server sends to another server includes just > one field - the server's id (long). This is in QuorumCnxManager.java. This > makes changes to the information passed during this initial connection very > difficult. This patch will change the first field of the message to be a > protocol version (a negative number that can't be a server id). The second > field will be the server id. The third field is number of bytes in the > remainder of the message. A 3.4 server will read the first field as before, > but if this is a negative number it will read the second field to find the > server id, and then remove the remainder of the message from the stream. This > will not affect 3.4 since 3.4 and earlier servers send just the server id (so > the code in the patch will not run unless there is a server > 3.4 trying to > connect). This will, however, provide the necessary flexibility for future > releases as well as an upgrade path from 3.4 -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (ZOOKEEPER-1790) Deal with special ObserverId in QuorumCnxManager.receiveConnection
Alexander Shraer created ZOOKEEPER-1790: --- Summary: Deal with special ObserverId in QuorumCnxManager.receiveConnection Key: ZOOKEEPER-1790 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1790 Project: ZooKeeper Issue Type: Bug Components: server Affects Versions: 3.4.6, 3.5.0 Reporter: Alexander Shraer Assignee: Alexander Shraer Fix For: 3.4.6, 3.5.0 QuorumCnxManager.receiveConnection assumes that a negative sid means that this is a 3.5.0 server, which has a different communication protocol. This doesn't account for the fact that ObserverId = -1 is a special id that may be used by observers and is also negative. This requires a fix to trunk and a separate fix to 3.4 branch, where this function is different (see ZOOKEEPER-1633) -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (ZOOKEEPER-1633) Introduce a protocol version to connection initiation message
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13792124#comment-13792124 ] Raul Gutierrez Segales commented on ZOOKEEPER-1633: --- Are observers mandated to have -1 as their sid? (lots of test cases in the code base (and deployments!) use something > 0). Plus the docs don't indicate that -1 should be used: http://zookeeper.apache.org/doc/r3.3.1/zookeeperObservers.html. > Introduce a protocol version to connection initiation message > - > > Key: ZOOKEEPER-1633 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1633 > Project: ZooKeeper > Issue Type: Bug > Components: server >Reporter: Alexander Shraer >Assignee: Alexander Shraer > Fix For: 3.4.6 > > Attachments: ZOOKEEPER-1633.patch, ZOOKEEPER-1633-v4.patch, > ZOOKEEPER-1633-v4.patch, ZOOKEEPER-1633-ver2.patch, ZOOKEEPER-1633-ver3.patch > > > Currently the first message a server sends to another server includes just > one field - the server's id (long). This is in QuorumCnxManager.java. This > makes changes to the information passed during this initial connection very > difficult. This patch will change the first field of the message to be a > protocol version (a negative number that can't be a server id). The second > field will be the server id. The third field is number of bytes in the > remainder of the message. A 3.4 server will read the first field as before, > but if this is a negative number it will read the second field to find the > server id, and then remove the remainder of the message from the stream. This > will not affect 3.4 since 3.4 and earlier servers send just the server id (so > the code in the patch will not run unless there is a server > 3.4 trying to > connect). This will, however, provide the necessary flexibility for future > releases as well as an upgrade path from 3.4 -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (ZOOKEEPER-1789) 3.4.x observer causes NPE on 3.5.0 (trunk) participants
[
https://issues.apache.org/jira/browse/ZOOKEEPER-1789?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13792123#comment-13792123
]
Alexander Shraer commented on ZOOKEEPER-1789:
-
thanks once again Raul. Yeah, I guess it should be getView instead of
getVotingView, or something similar. It is possible, however, that the sid is
not there so the following code should deal with the case that electionAddr is
null, perhaps by calling connectOne(sid) instead of connectOne(sid,
electionAddr), but I'm not completely sure.
You may also want to look at ZK-1633. CnxManagerTest.java is where to look for
test examples for this one.
There seems to be a related bug - observers may not be declared in the view and
have a special id (although if they fall within this "if" like you describe
they have positive id so they should be in getView). See the code below the
one you quote in how it deals with special ObserverId = -1.
It would be great if you can fix and test the bug you identified, dealing also
with the case that electionAddr may be end up being null if the id is not in
the view. I can then fix the remaining issue of special ObserverId.
> 3.4.x observer causes NPE on 3.5.0 (trunk) participants
> ---
>
> Key: ZOOKEEPER-1789
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1789
> Project: ZooKeeper
> Issue Type: Bug
>Reporter: Raul Gutierrez Segales
>Assignee: Alexander Shraer
>
> (assigning to Alex because this was introduced by ZOOKEEPER-107, but will
> upload a patch as well.)
> I have a 5 participants cluster running what will be 3.5.0 (i.e.: trunk as of
> today) and an observer running 3.4 (trunk from 3.4 branch). When the observer
> tries to establish a connection to the participants I get:
> {noformat}
> Thread Thread[10.40.78.121:3888,5,main] died java.lang.NullPointerException
> at
> org.apache.zookeeper.server.quorum.QuorumCnxManager.receiveConnection(QuorumCnxManager.java:240)
> at
> org.apache.zookeeper.server.quorum.QuorumCnxManager$Listener.run(QuorumCnxManager.java:552)
> {noformat}
> Looking at QuorumCnxManager.java:240:
> {noformat}
> if (protocolVersion >= 0) { // this is a server id and not a
> protocol version
>sid = protocolVersion;
> electionAddr = self.getVotingView().get(sid).electionAddr;
> } else {
> {noformat}
> and self.getVotingView().get(sid) will be null for Observers. So this block
> should cover that case.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (ZOOKEEPER-1633) Introduce a protocol version to connection initiation message
[
https://issues.apache.org/jira/browse/ZOOKEEPER-1633?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13792114#comment-13792114
]
Alexander Shraer commented on ZOOKEEPER-1633:
-
Seems like there is a small bug in the patch. Instead of "if (sid < 0) {" it
should say "if (sid < -1)" because of the special ObserverId which is -1.
> Introduce a protocol version to connection initiation message
> -
>
> Key: ZOOKEEPER-1633
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1633
> Project: ZooKeeper
> Issue Type: Bug
> Components: server
>Reporter: Alexander Shraer
>Assignee: Alexander Shraer
> Fix For: 3.4.6
>
> Attachments: ZOOKEEPER-1633.patch, ZOOKEEPER-1633-v4.patch,
> ZOOKEEPER-1633-v4.patch, ZOOKEEPER-1633-ver2.patch, ZOOKEEPER-1633-ver3.patch
>
>
> Currently the first message a server sends to another server includes just
> one field - the server's id (long). This is in QuorumCnxManager.java. This
> makes changes to the information passed during this initial connection very
> difficult. This patch will change the first field of the message to be a
> protocol version (a negative number that can't be a server id). The second
> field will be the server id. The third field is number of bytes in the
> remainder of the message. A 3.4 server will read the first field as before,
> but if this is a negative number it will read the second field to find the
> server id, and then remove the remainder of the message from the stream. This
> will not affect 3.4 since 3.4 and earlier servers send just the server id (so
> the code in the patch will not run unless there is a server > 3.4 trying to
> connect). This will, however, provide the necessary flexibility for future
> releases as well as an upgrade path from 3.4
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (ZOOKEEPER-1106) mt c client core when create node
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13792108#comment-13792108 ] Hadoop QA commented on ZOOKEEPER-1106: -- -1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12493262/patch.txt against trunk revision 1531061. +1 @author. The patch does not contain any @author tags. -1 tests included. The patch doesn't appear to include any new or modified tests. Please justify why no new tests are needed for this patch. Also please list what manual steps were performed to verify this patch. -1 patch. The patch command could not apply the patch. Console output: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1677//console This message is automatically generated. > mt c client core when create node > -- > > Key: ZOOKEEPER-1106 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1106 > Project: ZooKeeper > Issue Type: Bug > Components: c client >Affects Versions: 3.3.2 >Reporter: jiang guangran > Attachments: patch.txt > > > in deserialize_CreateResponse >rc = rc ? : in->deserialize_String(in, "path", &v->path); >in deserialize_String > len = -1 > so v->path is uninitialised, and free, so core > do_io thread > #0 0x0039fb030265 in raise () from /lib64/libc.so.6 > #1 0x0039fb031d10 in abort () from /lib64/libc.so.6 > #2 0x0039fb06a84b in __libc_message () from /lib64/libc.so.6 > #3 0x0039fb0722ef in _int_free () from /lib64/libc.so.6 > #4 0x0039fb07273b in free () from /lib64/libc.so.6 > #5 0x2b0afd755dd1 in deallocate_String (s=0x5a490f40) at > src/recordio.c:29 > #6 0x2b0afd754ade in zookeeper_process (zh=0x131e3870, events= optimized out>) at src/zookeeper.c:2071 > #7 0x2b0afd75b2ef in do_io (v=) at > src/mt_adaptor.c:310 > #8 0x0039fb8064a7 in start_thread () from /lib64/libpthread.so.0 > #9 0x0039fb0d3c2d in clone () from /lib64/libc.so.6 > create_node thread > #0 0x0039fb80ab99 in pthread_cond_wait@@GLIBC_2.3.2 () from > /lib64/libpthread.so.0 > #1 0x2b0afd75af5c in wait_sync_completion (sc=0x131e4c90) at > src/mt_adaptor.c:82 > #2 0x2b0afd751750 in zoo_create (zh=0x131e3870, path=0x13206fa8 > "/jsq/zr2/hb/10.250.8.139:8102", > value=0x131e86a8 > "\n\021\061\060.250.8.139:8102\022\035/home/shaoqiang/workdir2/qrs/\030\001 > \001*%\n\020\n", > valuelen=102, acl=0x2b0afd961700, flags=1, path_buffer=0x0, > path_buffer_len=0) at src/zookeeper.c:3028 -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (ZOOKEEPER-1183) Enhance LogFormatter to output additional detail from transaction log
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13792106#comment-13792106 ] Hadoop QA commented on ZOOKEEPER-1183: -- -1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12495006/ZOOKEEPER-1183.patch against trunk revision 1531061. +1 @author. The patch does not contain any @author tags. -1 tests included. The patch doesn't appear to include any new or modified tests. Please justify why no new tests are needed for this patch. Also please list what manual steps were performed to verify this patch. -1 patch. The patch command could not apply the patch. Console output: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1676//console This message is automatically generated. > Enhance LogFormatter to output additional detail from transaction log > - > > Key: ZOOKEEPER-1183 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1183 > Project: ZooKeeper > Issue Type: Improvement >Affects Versions: 3.4.0 >Reporter: kishore gopalakrishna >Assignee: kishore gopalakrishna >Priority: Minor > Attachments: ZOOKEEPER-1183.patch > > > Current LogFormatter prints the following information > ZooKeeper Transactional Log File with dbid 0 txnlog format version 2 > 8/15/11 1:55:36 PM PDT session 0x131cf1a236f0014 cxid 0x0 zxid 0xf01 > createSession > 8/15/11 1:55:57 PM PDT session 0x131cf1a236f cxid 0x55f zxid 0xf02 setData > 8/15/11 1:56:00 PM PDT session 0x131cf1a236f0015 cxid 0x0 zxid 0xf03 > createSession > ... > .. > 8/15/11 2:00:33 PM PDT session 0x131cf1a236f001c cxid 0x36 zxid 0xf6b setData > 8/15/11 2:00:33 PM PDT session 0x131cf1a236f0021 cxid 0xa1 zxid 0xf6c create > 8/15/11 2:00:33 PM PDT session 0x131cf1a236f001b cxid 0x3e zxid 0xf6d setData > 8/15/11 2:00:33 PM PDT session 0x131cf1a236f001e cxid 0x3e zxid 0xf6e setData > 8/15/11 2:00:33 PM PDT session 0x131cf1a236f001d cxid 0x41 zxid 0xf6f setData > Though this is good information, it does not provide additional information > like > createSession: which ip created the session and its time out > set|get|delete: the path and data > create: path created and createmode along with data > We can add additional parameter -detail and provide detailed output of the > transaction. > Outputting data is slightly tricky since we cant print data without > understanding the format. We need not print this for now. -- This message was sent by Atlassian JIRA (v6.1#6144)
Failed: ZOOKEEPER-1106 PreCommit Build #1677
Jira: https://issues.apache.org/jira/browse/ZOOKEEPER-1106 Build: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1677/ ### ## LAST 60 LINES OF THE CONSOLE ### [...truncated 68 lines...] [exec] Applying patch. [exec] == [exec] == [exec] [exec] [exec] patching file recordio.c [exec] Hunk #1 FAILED at 266. [exec] 1 out of 1 hunk FAILED -- saving rejects to file recordio.c.rej [exec] PATCH APPLICATION FAILED [exec] [exec] [exec] [exec] [exec] -1 overall. Here are the results of testing the latest attachment [exec] http://issues.apache.org/jira/secure/attachment/12493262/patch.txt [exec] against trunk revision 1531061. [exec] [exec] +1 @author. The patch does not contain any @author tags. [exec] [exec] -1 tests included. The patch doesn't appear to include any new or modified tests. [exec] Please justify why no new tests are needed for this patch. [exec] Also please list what manual steps were performed to verify this patch. [exec] [exec] -1 patch. The patch command could not apply the patch. [exec] [exec] Console output: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1677//console [exec] [exec] This message is automatically generated. [exec] [exec] [exec] == [exec] == [exec] Adding comment to Jira. [exec] == [exec] == [exec] [exec] [exec] Comment added. [exec] da7ad53dcaca21ae5a950cad583e02b113537e94 logged out [exec] [exec] [exec] == [exec] == [exec] Finished build. [exec] == [exec] == [exec] [exec] BUILD FAILED /home/jenkins/jenkins-slave/workspace/PreCommit-ZOOKEEPER-Build/trunk/build.xml:1623: exec returned: 1 Total time: 50 seconds Build step 'Execute shell' marked build as failure Archiving artifacts Recording test results Description set: ZOOKEEPER-1106 Email was triggered for: Failure Sending email for trigger: Failure ### ## FAILED TESTS (if any) ## No tests ran.
Failed: ZOOKEEPER-1183 PreCommit Build #1676
Jira: https://issues.apache.org/jira/browse/ZOOKEEPER-1183 Build: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1676/ ### ## LAST 60 LINES OF THE CONSOLE ### [...truncated 70 lines...] [exec] [exec] [exec] patching file src/java/main/org/apache/zookeeper/server/LogFormatter.java [exec] patching file src/java/main/org/apache/zookeeper/server/TraceFormatter.java [exec] Reversed (or previously applied) patch detected! Assume -R? [n] [exec] Apply anyway? [n] [exec] Skipping patch. [exec] 1 out of 1 hunk ignored -- saving rejects to file src/java/main/org/apache/zookeeper/server/TraceFormatter.java.rej [exec] PATCH APPLICATION FAILED [exec] [exec] [exec] [exec] [exec] -1 overall. Here are the results of testing the latest attachment [exec] http://issues.apache.org/jira/secure/attachment/12495006/ZOOKEEPER-1183.patch [exec] against trunk revision 1531061. [exec] [exec] +1 @author. The patch does not contain any @author tags. [exec] [exec] -1 tests included. The patch doesn't appear to include any new or modified tests. [exec] Please justify why no new tests are needed for this patch. [exec] Also please list what manual steps were performed to verify this patch. [exec] [exec] -1 patch. The patch command could not apply the patch. [exec] [exec] Console output: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1676//console [exec] [exec] This message is automatically generated. [exec] [exec] [exec] == [exec] == [exec] Adding comment to Jira. [exec] == [exec] == [exec] [exec] [exec] Comment added. [exec] 6c52af43c2f3993281a1464ded446d25838e27fa logged out [exec] [exec] [exec] == [exec] == [exec] Finished build. [exec] == [exec] == [exec] [exec] BUILD FAILED /home/jenkins/jenkins-slave/workspace/PreCommit-ZOOKEEPER-Build/trunk/build.xml:1623: exec returned: 1 Total time: 46 seconds Build step 'Execute shell' marked build as failure Archiving artifacts Recording test results Description set: ZOOKEEPER-1183 Email was triggered for: Failure Sending email for trigger: Failure ### ## FAILED TESTS (if any) ## No tests ran.
[jira] [Commented] (ZOOKEEPER-802) Improved LogGraph filters + documentation
[ https://issues.apache.org/jira/browse/ZOOKEEPER-802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13792105#comment-13792105 ] Patrick Hunt commented on ZOOKEEPER-802: Hi [~ikelly], loggraph is still in contribs. Should we continue to maintain it? If so we might want to get this in and ensure loggraph works with 3.4/3.5/etc... > Improved LogGraph filters + documentation > - > > Key: ZOOKEEPER-802 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-802 > Project: ZooKeeper > Issue Type: Improvement >Affects Versions: 3.4.0 >Reporter: Ivan Kelly >Assignee: Ivan Kelly >Priority: Minor > Fix For: 3.5.0 > > Attachments: logs.tar.gz, ZOOKEEPER-802.patch, ZOOKEEPER-802.patch, > ZOOKEEPER-802.patch, ZOOKEEPER-802.patch, ZOOKEEPER-802.patch > > > The log filtering mechanism has been improved and extended to work with > message logs. Also, the documentation has been moved into the forrest > documentation. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (ZOOKEEPER-700) GSoC 2010: FUSE module for BookKeeper
[ https://issues.apache.org/jira/browse/ZOOKEEPER-700?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Hunt updated ZOOKEEPER-700: --- Description: FUSE module for BookKeeper Possible Mentor Ben Reed (breed at apache dot org) Requirements C/Java, some networking familiarity Description BookKeeper is a distributed write ahead log with client & server written in Java. BookKeeper client & server also use ZooKeeper. There is a BookKeeper API that clients can use to integrate write ahead logging into their application. It would be a lot easier if applications could use BK without changes to the client application through use of a file system api (FUSE). The project would involve implementing a C interface for BookKeeper (Java already exists) and implementing the FUSE module. Example use: the write ahead log in mysql, called binlogs are typically written to the local filesystem using the std filesystem api. We could modify mysql to use BooKeeper, however if we had a BK FUSE module we could run it (mysql) w/o any modification and get the performance/reliability of a distributed write ahead log. was: FUSE module for BookKeeper Possible Mentor Ben Reed (breed at apache dot org) & Patrick Hunt (phunt at apache dot org) Requirements C/Java, some networking familiarity Description BookKeeper is a distributed write ahead log with client & server written in Java. BookKeeper client & server also use ZooKeeper. There is a BookKeeper API that clients can use to integrate write ahead logging into their application. It would be a lot easier if applications could use BK without changes to the client application through use of a file system api (FUSE). The project would involve implementing a C interface for BookKeeper (Java already exists) and implementing the FUSE module. Example use: the write ahead log in mysql, called binlogs are typically written to the local filesystem using the std filesystem api. We could modify mysql to use BooKeeper, however if we had a BK FUSE module we could run it (mysql) w/o any modification and get the performance/reliability of a distributed write ahead log. > GSoC 2010: FUSE module for BookKeeper > - > > Key: ZOOKEEPER-700 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-700 > Project: ZooKeeper > Issue Type: Wish >Reporter: Henry Robinson > Labels: gsoc, mentor > > FUSE module for BookKeeper > Possible Mentor > Ben Reed (breed at apache dot org) > Requirements > C/Java, some networking familiarity > Description > BookKeeper is a distributed write ahead log with client & server written in > Java. BookKeeper client & server also use ZooKeeper. There is a BookKeeper > API that clients can use to integrate write ahead logging into their > application. It would be a lot easier if applications could use BK without > changes to the client application through use of a file system api (FUSE). > The project would involve implementing a C interface for BookKeeper (Java > already exists) and implementing the FUSE module. > Example use: the write ahead log in mysql, called binlogs are typically > written to the local filesystem using the std filesystem api. We could modify > mysql to use BooKeeper, however if we had a BK FUSE module we could run it > (mysql) w/o any modification and get the performance/reliability of a > distributed write ahead log. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Moved] (BOOKKEEPER-693) Review of BookKeeper Documentation (Sequence flow and failure scenarios)
[ https://issues.apache.org/jira/browse/BOOKKEEPER-693?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Hunt moved ZOOKEEPER-918 to BOOKKEEPER-693: --- Component/s: (was: documentation) Fix Version/s: (was: 3.5.0) Assignee: (was: Amit Jaiswal) Key: BOOKKEEPER-693 (was: ZOOKEEPER-918) Project: Bookkeeper (was: ZooKeeper) > Review of BookKeeper Documentation (Sequence flow and failure scenarios) > > > Key: BOOKKEEPER-693 > URL: https://issues.apache.org/jira/browse/BOOKKEEPER-693 > Project: Bookkeeper > Issue Type: Task >Reporter: Amit Jaiswal >Priority: Minor > Attachments: BookKeeperInternals.doc, BookKeeperInternals.pdf > > Original Estimate: 2h > Remaining Estimate: 2h > > I have prepared a document describing some of the internals of bookkeeper in > terms of: > 1. Sequence of operations > 2. Files layout > 3. Failure scenarios > The document is prepared by mostly by reading the code. Can somebody who > understands the design review the same. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (ZOOKEEPER-639) Performance improvements for ZooKeeper
[ https://issues.apache.org/jira/browse/ZOOKEEPER-639?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Hunt updated ZOOKEEPER-639: --- Assignee: Benjamin Reed > Performance improvements for ZooKeeper > -- > > Key: ZOOKEEPER-639 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-639 > Project: ZooKeeper > Issue Type: Improvement > Components: server >Reporter: Benjamin Reed >Assignee: Benjamin Reed > Attachments: ZOOKEEPER-639.patch > > > here are some more improvements to Zab. the patch is a bit stale, but i don't > want to lose track of it. there are two big improvements: > 1) transaction logs are reused. this saves time over growing the log files > and if you preallocate a bunch of log files on an empty partition, you will > see a nice performance boost > 2) acks and commits are always sent in order, so if there is a bunch to send, > they will get merged into a single ack or commit. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Created] (ZOOKEEPER-1789) 3.4.x observer causes NPE on 3.5.0 (trunk) participants
Raul Gutierrez Segales created ZOOKEEPER-1789:
-
Summary: 3.4.x observer causes NPE on 3.5.0 (trunk) participants
Key: ZOOKEEPER-1789
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1789
Project: ZooKeeper
Issue Type: Bug
Reporter: Raul Gutierrez Segales
Assignee: Alexander Shraer
(assigning to Alex because this was introduced by ZOOKEEPER-107, but will
upload a patch as well.)
I have a 5 participants cluster running what will be 3.5.0 (i.e.: trunk as of
today) and an observer running 3.4 (trunk from 3.4 branch). When the observer
tries to establish a connection to the participants I get:
{noformat}
Thread Thread[10.40.78.121:3888,5,main] died java.lang.NullPointerException at
org.apache.zookeeper.server.quorum.QuorumCnxManager.receiveConnection(QuorumCnxManager.java:240)
at
org.apache.zookeeper.server.quorum.QuorumCnxManager$Listener.run(QuorumCnxManager.java:552)
{noformat}
Looking at QuorumCnxManager.java:240:
{noformat}
if (protocolVersion >= 0) { // this is a server id and not a
protocol version
sid = protocolVersion;
electionAddr = self.getVotingView().get(sid).electionAddr;
} else {
{noformat}
and self.getVotingView().get(sid) will be null for Observers. So this block
should cover that case.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
Re: Compile for ARM
I have not seen this issue but please do consider submitting a patch. https://cwiki.apache.org/confluence/display/ZOOKEEPER/HowToContribute Patrick On Thu, Oct 10, 2013 at 11:46 AM, Niklas Molin wrote: > Hi. > > I just downloaded version 3.4.5 to compile on a Freescale (ARM). > I got an error when it tried to compile the assembly code: > Error: bad instruction `lock xaddl r1,[r0,#0]' > And this seems to be from the file mt_adaptor.c > > I saw in the function fetch_and_add(...) that is was using inline assembly > code and that seems to have been the problem. > > I saw in an earlier patch for the zookeeper that in the file > /test/ThreadingUtil.cc there was a similar problem and it was fixed by > "replace" the assembly code with a call to __sync_fetch_and_add instead > (when __GNUC__ is defined). > Seems to compile okay when I do the same patch in the mt_adaptor.c > > Has someone else seen this compiler error? > > Thanks, > Niklas
[jira] [Commented] (ZOOKEEPER-1768) Cluster fails election loop until the device is full
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13791971#comment-13791971 ] Flavio Junqueira commented on ZOOKEEPER-1768: - My interpretation of the problem is that syncing is taking too long. The one problem we could consider fixing here, if I understand the issue right, is that we delete the snapshot in the case the follower doesn't complete the sync. The follower seems to be accumulating incomplete snapshots on disk, which eventually makes the disk full. We could consider it for 3.4.6, but it doesn't look like a blocker to me. Does anyone disagree? > Cluster fails election loop until the device is full > > > Key: ZOOKEEPER-1768 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1768 > Project: ZooKeeper > Issue Type: Bug > Components: leaderElection >Affects Versions: 3.4.5 >Reporter: yuxin.yan > Fix For: 3.4.6, 3.5.0 > > Attachments: zk_debug.log.2013-09-25.log, zoo.cfg > > > Hi, > I have a five nodes cluster versioned 3.4.5 and now i find one node is > offline. > Firstly i restart the node but i find that "Error contacting service. It is > probably not running." and i find that the node always elect the leader and > always sync the snapshot logs and the device will be full every ten mins. > so could someone help me？ i will put the log and zoo.cfg in the attachment. > Thanks all. > yyx, -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (ZOOKEEPER-1768) Cluster fails election loop until the device is full
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Flavio Junqueira updated ZOOKEEPER-1768: Fix Version/s: 3.5.0 3.4.6 > Cluster fails election loop until the device is full > > > Key: ZOOKEEPER-1768 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1768 > Project: ZooKeeper > Issue Type: Bug > Components: leaderElection >Affects Versions: 3.4.5 >Reporter: yuxin.yan > Fix For: 3.4.6, 3.5.0 > > Attachments: zk_debug.log.2013-09-25.log, zoo.cfg > > > Hi, > I have a five nodes cluster versioned 3.4.5 and now i find one node is > offline. > Firstly i restart the node but i find that "Error contacting service. It is > probably not running." and i find that the node always elect the leader and > always sync the snapshot logs and the device will be full every ten mins. > so could someone help me？ i will put the log and zoo.cfg in the attachment. > Thanks all. > yyx, -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (ZOOKEEPER-1115) follower can not sync with leader
[
https://issues.apache.org/jira/browse/ZOOKEEPER-1115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Flavio Junqueira resolved ZOOKEEPER-1115.
-
Resolution: Not A Problem
I'm resolving this one as not a problem, given the discussion in the jira, and
please feel free to reopen if needed. Also, note that this jira was created for
the 3.3 branch, and we've been recommending that users move to the 3.4 branch.
> follower can not sync with leader
> -
>
> Key: ZOOKEEPER-1115
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1115
> Project: ZooKeeper
> Issue Type: Bug
> Components: quorum
>Affects Versions: 3.3.0, 3.3.3
> Environment: linux rhel 4, x64, java version 1.4.2
>Reporter: helei
>Priority: Critical
>
> there are 5 members in the quorum. one follower can not sync with leader
> after restart. it seems leader has close the data connection with this
> follower because of read timeout. here is the key log in follower:
> {noformat}
> 2011-06-30 22:14:45,069 - WARN [Thread-17:QuorumCnxManager$RecvWorker@658] -
> Connection broken:
> java.nio.channels.ClosedChannelException
> at
> sun.nio.ch.SocketChannelImpl.ensureReadOpen(SocketChannelImpl.java:113)
> at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:156)
> at
> org.apache.zookeeper.server.quorum.QuorumCnxManager$RecvWorker.run(QuorumCnxManager.java:629)
> 2011-06-30 22:14:45,069 - INFO
> [QuorumPeer:/0.0.0.0:2181:FastLeaderElection@689] - Notification: 3,
> 17198470148, 3, 3, LOOKING, LOOKING, 3
> 2011-06-30 22:14:45,070 - ERROR [Thread-16:QuorumCnxManager$SendWorker@559] -
> Failed to send last message. Shutting down thread.
> java.nio.channels.ClosedChannelException
> at
> sun.nio.ch.SocketChannelImpl.ensureWriteOpen(SocketChannelImpl.java:126)
> at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:324)
> at
> org.apache.zookeeper.server.quorum.QuorumCnxManager$SendWorker.send(QuorumCnxManager.java:548)
> at
> org.apache.zookeeper.server.quorum.QuorumCnxManager$SendWorker.run(QuorumCnxManager.java:557)
> 2011-06-30 22:14:45,082 - INFO [QuorumPeer:/0.0.0.0:2181:Learner@282] -
> Getting a diff from the leader 0x4011bd462
> 2011-06-30 22:14:45,083 - WARN [Thread-18:QuorumCnxManager$SendWorker@589] -
> Send worker leaving thread
> 2011-06-30 22:14:45,085 - WARN [QuorumPeer:/0.0.0.0:2181:Follower@116] - Got
> zxid 0x4011bd405 expected 0x1
> 2011-06-30 22:14:45,090 - INFO [QuorumPeer:/0.0.0.0:2181:FileTxnSnapLog@208]
> - Snapshotting: 4011bd462
> 2011-06-30 22:14:53,397 - WARN [SyncThread:3:SendAckRequestProcessor@63] -
> Closing connection to leader, exception during packet send
> java.net.SocketException: Broken pipe
> at java.net.SocketOutputStream.socketWrite0(Native Method)
> at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92)
> at java.net.SocketOutputStream.write(SocketOutputStream.java:136)
> at
> java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:65)
> at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:123)
> at
> org.apache.zookeeper.server.quorum.Learner.writePacket(Learner.java:126)
> at
> org.apache.zookeeper.server.quorum.SendAckRequestProcessor.flush(SendAckRequestProcessor.java:61)
> at
> org.apache.zookeeper.server.SyncRequestProcessor.flush(SyncRequestProcessor.java:164)
> at
> org.apache.zookeeper.server.SyncRequestProcessor.run(SyncRequestProcessor.java:98)
> 2011-06-30 22:14:53,398 - WARN [QuorumPeer:/0.0.0.0:2181:Follower@82] -
> Exception when following the leader
> java.net.SocketException: Socket closed
> at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:99)
> at java.net.SocketOutputStream.write(SocketOutputStream.java:136)
> at
> java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:65)
> at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:123)
> at
> org.apache.zookeeper.server.quorum.Learner.writePacket(Learner.java:126)
> at org.apache.zookeeper.server.quorum.Learner.ping(Learner.java:358)
> at
> org.apache.zookeeper.server.quorum.Follower.processPacket(Follower.java:108)
> at
> org.apache.zookeeper.server.quorum.Follower.followLeader(Follower.java:79)
> at
> org.apache.zookeeper.server.quorum.QuorumPeer.run(QuorumPeer.java:634)
> 2011-06-30 22:14:53,398 - WARN [SyncThread:3:SendAckRequestProcessor@63] -
> Closing connection to leader, exception during packet send
> java.net.SocketException: Socket closed
> at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:99)
> at java.net.SocketOutputStream.write(SocketOutputStream.java:136)
> at
> java.io.
[jira] [Commented] (ZOOKEEPER-1624) PrepRequestProcessor abort multi-operation incorrectly
[
https://issues.apache.org/jira/browse/ZOOKEEPER-1624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13791856#comment-13791856
]
Hudson commented on ZOOKEEPER-1624:
---
SUCCESS: Integrated in ZooKeeper-trunk #2085 (See
[https://builds.apache.org/job/ZooKeeper-trunk/2085/])
ZOOKEEPER-1624. PrepRequestProcessor abort multi-operation incorrectly. (thawan
via camille) (camille:
http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1531061)
* /zookeeper/trunk/CHANGES.txt
* /zookeeper/trunk/src/c/tests/TestMulti.cc
*
/zookeeper/trunk/src/java/main/org/apache/zookeeper/server/PrepRequestProcessor.java
*
/zookeeper/trunk/src/java/test/org/apache/zookeeper/test/MultiAsyncTransactionTest.java
> PrepRequestProcessor abort multi-operation incorrectly
> --
>
> Key: ZOOKEEPER-1624
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1624
> Project: ZooKeeper
> Issue Type: Bug
> Components: server
>Reporter: Thawan Kooburat
>Assignee: Thawan Kooburat
>Priority: Critical
> Labels: zk-review
> Fix For: 3.4.6, 3.5.0
>
> Attachments: ZOOKEEPER-1624-3.4, ZOOKEEPER-1624.patch,
> ZOOKEEPER-1624.patch, ZOOKEEPER-1624.patch, ZOOKEEPER-1624.patch,
> ZOOKEEPER-1624.patch
>
>
> We found this issue when trying to issue multiple instances of the following
> multi-op concurrently
> multi {
> 1. create sequential node /a-
> 2. create node /b
> }
> The expected result is that only the first multi-op request should success
> and the rest of request should fail because /b is already exist
> However, the reported result is that the subsequence multi-op failed because
> of sequential node creation failed which is not possible.
> Below is the return code for each sub-op when issuing 3 instances of the
> above multi-op asynchronously
> 1. ZOK, ZOK
> 2. ZOK, ZNODEEXISTS,
> 3. ZNODEEXISTS, ZRUNTIMEINCONSISTENCY,
> When I added more debug log. The cause is that PrepRequestProcessor rollback
> outstandingChanges of the second multi-op incorrectly causing sequential node
> name generation to be incorrect. Below is the sequential node name generated
> by PrepRequestProcessor
> 1. create /a-0001
> 2. create /a-0003
> 3. create /a-0001
> The bug is getPendingChanges() method. In failed to copied ChangeRecord for
> the parent node ("/"). So rollbackPendingChanges() cannot restore the right
> previous change record of the parent node when aborting the second multi-op
> The impact of this bug is that sequential node creation on the same parent
> node may fail until the previous one is committed. I am not sure if there is
> other implication or not.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (ZOOKEEPER-1558) Leader should not snapshot uncommitted state
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13791843#comment-13791843 ] Thawan Kooburat commented on ZOOKEEPER-1558: Yeah, I think that should work as well. Seem like a new txnlog file is produced on a new epoch so that should be fine. I am wondering if we should apply this to 3.5 so at least the problem in 1549 is partially fixed in trunk as well before 1549 land and we also get more testing. > Leader should not snapshot uncommitted state > > > Key: ZOOKEEPER-1558 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1558 > Project: ZooKeeper > Issue Type: Sub-task > Components: quorum >Affects Versions: 3.4.6 >Reporter: Flavio Junqueira >Assignee: Flavio Junqueira >Priority: Blocker > Fix For: 3.4.6 > > Attachments: ZOOKEEPER-1558.patch, ZOOKEEPER-1558.patch, > ZOOKEEPER-1558.patch, ZOOKEEPER-1558.patch, ZOOKEEPER-1558.patch > > > Leader currently takes a snapshot when it calls loadData in the beginning of > the lead() method. The loaded data, however, may contain uncommitted state. -- This message was sent by Atlassian JIRA (v6.1#6144)
Compile for ARM
Hi. I just downloaded version 3.4.5 to compile on a Freescale (ARM). I got an error when it tried to compile the assembly code: Error: bad instruction `lock xaddl r1,[r0,#0]' And this seems to be from the file mt_adaptor.c I saw in the function fetch_and_add(...) that is was using inline assembly code and that seems to have been the problem. I saw in an earlier patch for the zookeeper that in the file /test/ThreadingUtil.cc there was a similar problem and it was fixed by "replace" the assembly code with a call to __sync_fetch_and_add instead (when __GNUC__ is defined). Seems to compile okay when I do the same patch in the mt_adaptor.c Has someone else seen this compiler error? Thanks, Niklas
Failed: ZOOKEEPER-1744 PreCommit Build #1675
Jira: https://issues.apache.org/jira/browse/ZOOKEEPER-1744 Build: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1675/ ### ## LAST 60 LINES OF THE CONSOLE ### [...truncated 298820 lines...] [exec] [exec] -1 overall. Here are the results of testing the latest attachment [exec] http://issues.apache.org/jira/secure/attachment/12599508/ZOOKEEPER-1744.patch [exec] against trunk revision 1530809. [exec] [exec] +1 @author. The patch does not contain any @author tags. [exec] [exec] -1 tests included. The patch doesn't appear to include any new or modified tests. [exec] Please justify why no new tests are needed for this patch. [exec] Also please list what manual steps were performed to verify this patch. [exec] [exec] +1 javadoc. The javadoc tool did not generate any warning messages. [exec] [exec] +1 javac. The applied patch does not increase the total number of javac compiler warnings. [exec] [exec] +1 findbugs. The patch does not introduce any new Findbugs (version 1.3.9) warnings. [exec] [exec] +1 release audit. The applied patch does not increase the total number of release audit warnings. [exec] [exec] +1 core tests. The patch passed core unit tests. [exec] [exec] +1 contrib tests. The patch passed contrib unit tests. [exec] [exec] Test results: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1675//testReport/ [exec] Findbugs warnings: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1675//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html [exec] Console output: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1675//console [exec] [exec] This message is automatically generated. [exec] [exec] [exec] == [exec] == [exec] Adding comment to Jira. [exec] == [exec] == [exec] [exec] [exec] Comment added. [exec] 5ae130954ea537231079aa3ace61bdf7b3506ea7 logged out [exec] [exec] [exec] == [exec] == [exec] Finished build. [exec] == [exec] == [exec] [exec] BUILD FAILED /home/jenkins/jenkins-slave/workspace/PreCommit-ZOOKEEPER-Build/trunk/build.xml:1623: exec returned: 1 Total time: 33 minutes 20 seconds Build step 'Execute shell' marked build as failure Archiving artifacts Recording test results Description set: ZOOKEEPER-1744 Email was triggered for: Failure Sending email for trigger: Failure ### ## FAILED TESTS (if any) ## All tests passed
[jira] [Commented] (ZOOKEEPER-1744) clientPortAddress breaks "zkServer.sh status"
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13791812#comment-13791812 ] Hadoop QA commented on ZOOKEEPER-1744: -- -1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12599508/ZOOKEEPER-1744.patch against trunk revision 1530809. +1 @author. The patch does not contain any @author tags. -1 tests included. The patch doesn't appear to include any new or modified tests. Please justify why no new tests are needed for this patch. Also please list what manual steps were performed to verify this patch. +1 javadoc. The javadoc tool did not generate any warning messages. +1 javac. The applied patch does not increase the total number of javac compiler warnings. +1 findbugs. The patch does not introduce any new Findbugs (version 1.3.9) warnings. +1 release audit. The applied patch does not increase the total number of release audit warnings. +1 core tests. The patch passed core unit tests. +1 contrib tests. The patch passed contrib unit tests. Test results: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1675//testReport/ Findbugs warnings: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1675//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html Console output: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1675//console This message is automatically generated. > clientPortAddress breaks "zkServer.sh status" > -- > > Key: ZOOKEEPER-1744 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1744 > Project: ZooKeeper > Issue Type: Bug > Components: scripts >Affects Versions: 3.4.5 >Reporter: Nick Ohanian >Assignee: Nick Ohanian >Priority: Critical > Fix For: 3.4.6, 3.5.0 > > Attachments: ZOOKEEPER-1744.patch > > > When "clientPortAddress" is used in the config file (zoo.cfg), zkServer.sh's > status command runs a grep command that matches both "clientPort" and > "clientPortAddress". This creates an extra argument for FourLetterWordMain, > which fails, so the status command incorrectly indicates that it couldn't > connect to the server. > Also, "localhost" is hardcoded as the target host for FourLetterWordMain. > The "clientPortAddress" should be used if it is provided in the config file. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (ZOOKEEPER-1744) clientPortAddress breaks "zkServer.sh status"
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13791781#comment-13791781 ] Alexander Shraer commented on ZOOKEEPER-1744: - right - I also don't think these are duplicate. My changes are extending the way clientPort is being identified, whereas here the patch is identifying the hostname to be used with this port. > clientPortAddress breaks "zkServer.sh status" > -- > > Key: ZOOKEEPER-1744 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1744 > Project: ZooKeeper > Issue Type: Bug > Components: scripts >Affects Versions: 3.4.5 >Reporter: Nick Ohanian >Assignee: Nick Ohanian >Priority: Critical > Fix For: 3.4.6, 3.5.0 > > Attachments: ZOOKEEPER-1744.patch > > > When "clientPortAddress" is used in the config file (zoo.cfg), zkServer.sh's > status command runs a grep command that matches both "clientPort" and > "clientPortAddress". This creates an extra argument for FourLetterWordMain, > which fails, so the status command incorrectly indicates that it couldn't > connect to the server. > Also, "localhost" is hardcoded as the target host for FourLetterWordMain. > The "clientPortAddress" should be used if it is provided in the config file. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (BOOKKEEPER-658) ledger cache refactor
[ https://issues.apache.org/jira/browse/BOOKKEEPER-658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13791754#comment-13791754 ] Sijie Guo commented on BOOKKEEPER-658: -- > the in memory manager has a handle on the persistent manager. Why not have it > make the calls on persistent manager, rather than calling both from > LedgerCacheImpl? we are trying decoupling in-memory part from persistence part and make a clear view from LedgerCache on what is in-memory and what is on disk and how they interacts. but unfortunately, some operations in InMemMgr needs to read a page from persistence manager. > ledger cache refactor > - > > Key: BOOKKEEPER-658 > URL: https://issues.apache.org/jira/browse/BOOKKEEPER-658 > Project: Bookkeeper > Issue Type: Sub-task > Components: bookkeeper-server >Reporter: Sijie Guo >Assignee: Robin Dhamankar > Fix For: 4.3.0 > > Attachments: 0001-BOOKKEEPER-658-ledger-cache-refactor.patch, > BOOKKEEPER-658.patch > > > refactor ledger cache to separate in-memory page management from persistent > management. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (ZOOKEEPER-1744) clientPortAddress breaks "zkServer.sh status"
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13791733#comment-13791733 ] Patrick Hunt commented on ZOOKEEPER-1744: - I could be wrong but I didn't think so, this is related to using clientport vs clientportaddress. It's an issue in 3.4. Alex's patch is for 3.5, dynamic reconfig changes related iiuc. > clientPortAddress breaks "zkServer.sh status" > -- > > Key: ZOOKEEPER-1744 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1744 > Project: ZooKeeper > Issue Type: Bug > Components: scripts >Affects Versions: 3.4.5 >Reporter: Nick Ohanian >Assignee: Nick Ohanian >Priority: Critical > Fix For: 3.4.6, 3.5.0 > > Attachments: ZOOKEEPER-1744.patch > > > When "clientPortAddress" is used in the config file (zoo.cfg), zkServer.sh's > status command runs a grep command that matches both "clientPort" and > "clientPortAddress". This creates an extra argument for FourLetterWordMain, > which fails, so the status command incorrectly indicates that it couldn't > connect to the server. > Also, "localhost" is hardcoded as the target host for FourLetterWordMain. > The "clientPortAddress" should be used if it is provided in the config file. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (ZOOKEEPER-1646) mt c client tests fail on Ubuntu Raring
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Hunt updated ZOOKEEPER-1646: Priority: Blocker (was: Minor) Fix Version/s: 3.4.6 Assignee: Patrick Hunt > mt c client tests fail on Ubuntu Raring > --- > > Key: ZOOKEEPER-1646 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1646 > Project: ZooKeeper > Issue Type: Bug > Components: c client >Affects Versions: 3.4.5 > Environment: Ubuntu 13.04 (raring), glibc 2.17 >Reporter: James Page >Assignee: Patrick Hunt >Priority: Blocker > Fix For: 3.4.6 > > > Misc tests fail in the c client binding under the current Ubuntu development > release: > ./zktest-mt > ZooKeeper server startedRunning > Zookeeper_clientretry::testRetry ZooKeeper server started ZooKeeper server > started : elapsed 9315 : OK > Zookeeper_operations::testAsyncWatcher1 : assertion : elapsed 1054 > Zookeeper_operations::testAsyncGetOperation : assertion : elapsed 1055 > Zookeeper_operations::testOperationsAndDisconnectConcurrently1 : assertion : > elapsed 1066 > Zookeeper_operations::testOperationsAndDisconnectConcurrently2 : elapsed 0 : > OK > Zookeeper_operations::testConcurrentOperations1 : assertion : elapsed 1055 > Zookeeper_init::testBasic : elapsed 1 : OK > Zookeeper_init::testAddressResolution : elapsed 0 : OK > Zookeeper_init::testMultipleAddressResolution : elapsed 0 : OK > Zookeeper_init::testNullAddressString : elapsed 0 : OK > Zookeeper_init::testEmptyAddressString : elapsed 0 : OK > Zookeeper_init::testOneSpaceAddressString : elapsed 0 : OK > Zookeeper_init::testTwoSpacesAddressString : elapsed 0 : OK > Zookeeper_init::testInvalidAddressString1 : elapsed 0 : OK > Zookeeper_init::testInvalidAddressString2 : elapsed 175 : OK > Zookeeper_init::testNonexistentHost : elapsed 92 : OK > Zookeeper_init::testOutOfMemory_init : elapsed 0 : OK > Zookeeper_init::testOutOfMemory_getaddrs1 : elapsed 0 : OK > Zookeeper_init::testOutOfMemory_getaddrs2 : elapsed 1 : OK > Zookeeper_init::testPermuteAddrsList : elapsed 0 : OK > Zookeeper_close::testIOThreadStoppedOnExpire : assertion : elapsed 1056 > Zookeeper_close::testCloseUnconnected : elapsed 0 : OK > Zookeeper_close::testCloseUnconnected1 : elapsed 91 : OK > Zookeeper_close::testCloseConnected1 : assertion : elapsed 1056 > Zookeeper_close::testCloseFromWatcher1 : assertion : elapsed 1076 > Zookeeper_simpleSystem::testAsyncWatcherAutoReset ZooKeeper server started : > elapsed 12155 : OK > Zookeeper_simpleSystem::testDeserializeString : elapsed 0 : OK > Zookeeper_simpleSystem::testNullData : elapsed 1031 : OK > Zookeeper_simpleSystem::testIPV6 : elapsed 1005 : OK > Zookeeper_simpleSystem::testPath : elapsed 1024 : OK > Zookeeper_simpleSystem::testPathValidation : elapsed 1053 : OK > Zookeeper_simpleSystem::testPing : elapsed 17287 : OK > Zookeeper_simpleSystem::testAcl : elapsed 1019 : OK > Zookeeper_simpleSystem::testChroot : elapsed 3052 : OK > Zookeeper_simpleSystem::testAuth : assertion : elapsed 7010 > Zookeeper_simpleSystem::testHangingClient : elapsed 1015 : OK > Zookeeper_simpleSystem::testWatcherAutoResetWithGlobal ZooKeeper server > started ZooKeeper server started ZooKeeper server started : elapsed 20556 : OK > Zookeeper_simpleSystem::testWatcherAutoResetWithLocal ZooKeeper server > started ZooKeeper server started ZooKeeper server started : elapsed 20563 : OK > Zookeeper_simpleSystem::testGetChildren2 : elapsed 1041 : OK > Zookeeper_multi::testCreate : elapsed 1017 : OK > Zookeeper_multi::testCreateDelete : elapsed 1007 : OK > Zookeeper_multi::testInvalidVersion : elapsed 1011 : OK > Zookeeper_multi::testNestedCreate : elapsed 1009 : OK > Zookeeper_multi::testSetData : elapsed 6019 : OK > Zookeeper_multi::testUpdateConflict : elapsed 1014 : OK > Zookeeper_multi::testDeleteUpdateConflict : elapsed 1007 : OK > Zookeeper_multi::testAsyncMulti : elapsed 2001 : OK > Zookeeper_multi::testMultiFail : elapsed 1006 : OK > Zookeeper_multi::testCheck : elapsed 1020 : OK > Zookeeper_multi::testWatch : elapsed 2013 : OK > Zookeeper_watchers::testDefaultSessionWatcher1zktest-mt: > tests/ZKMocks.cc:271: SyncedBoolCondition > DeliverWatchersWrapper::isDelivered() const: Assertion `i<1000' failed. > Aborted (core dumped) > It would appear that the zookeeper connection does not transition to > connected within the required time; I increased the time allowed but no > change. > Ubuntu raring has glibc 2.17; the test suite works fine on previous Ubuntu > releases and this is the only difference that stood out. > Interestingly the cli_mt worked just fine connecting to the same zookeeper > instance that the tests left lying around so I'm assuming this is a test > error rather than an actual bug. -- This message was sent by Atlassi
[jira] [Commented] (ZOOKEEPER-1744) clientPortAddress breaks "zkServer.sh status"
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13791728#comment-13791728 ] Camille Fournier commented on ZOOKEEPER-1744: - Isn't this a dupe of another patch ZOOKEEPER-1785? [~shralex] > clientPortAddress breaks "zkServer.sh status" > -- > > Key: ZOOKEEPER-1744 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1744 > Project: ZooKeeper > Issue Type: Bug > Components: scripts >Affects Versions: 3.4.5 >Reporter: Nick Ohanian >Assignee: Nick Ohanian >Priority: Critical > Fix For: 3.4.6, 3.5.0 > > Attachments: ZOOKEEPER-1744.patch > > > When "clientPortAddress" is used in the config file (zoo.cfg), zkServer.sh's > status command runs a grep command that matches both "clientPort" and > "clientPortAddress". This creates an extra argument for FourLetterWordMain, > which fails, so the status command incorrectly indicates that it couldn't > connect to the server. > Also, "localhost" is hardcoded as the target host for FourLetterWordMain. > The "clientPortAddress" should be used if it is provided in the config file. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (ZOOKEEPER-1646) mt c client tests fail on Ubuntu Raring
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13791725#comment-13791725 ] Patrick Hunt commented on ZOOKEEPER-1646: - ZOOKEEPER-1646 is the same issue as my comment on ZOOKEEPER-1742 > mt c client tests fail on Ubuntu Raring > --- > > Key: ZOOKEEPER-1646 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1646 > Project: ZooKeeper > Issue Type: Bug > Components: c client >Affects Versions: 3.4.5 > Environment: Ubuntu 13.04 (raring), glibc 2.17 >Reporter: James Page >Priority: Minor > Fix For: 3.4.6 > > > Misc tests fail in the c client binding under the current Ubuntu development > release: > ./zktest-mt > ZooKeeper server startedRunning > Zookeeper_clientretry::testRetry ZooKeeper server started ZooKeeper server > started : elapsed 9315 : OK > Zookeeper_operations::testAsyncWatcher1 : assertion : elapsed 1054 > Zookeeper_operations::testAsyncGetOperation : assertion : elapsed 1055 > Zookeeper_operations::testOperationsAndDisconnectConcurrently1 : assertion : > elapsed 1066 > Zookeeper_operations::testOperationsAndDisconnectConcurrently2 : elapsed 0 : > OK > Zookeeper_operations::testConcurrentOperations1 : assertion : elapsed 1055 > Zookeeper_init::testBasic : elapsed 1 : OK > Zookeeper_init::testAddressResolution : elapsed 0 : OK > Zookeeper_init::testMultipleAddressResolution : elapsed 0 : OK > Zookeeper_init::testNullAddressString : elapsed 0 : OK > Zookeeper_init::testEmptyAddressString : elapsed 0 : OK > Zookeeper_init::testOneSpaceAddressString : elapsed 0 : OK > Zookeeper_init::testTwoSpacesAddressString : elapsed 0 : OK > Zookeeper_init::testInvalidAddressString1 : elapsed 0 : OK > Zookeeper_init::testInvalidAddressString2 : elapsed 175 : OK > Zookeeper_init::testNonexistentHost : elapsed 92 : OK > Zookeeper_init::testOutOfMemory_init : elapsed 0 : OK > Zookeeper_init::testOutOfMemory_getaddrs1 : elapsed 0 : OK > Zookeeper_init::testOutOfMemory_getaddrs2 : elapsed 1 : OK > Zookeeper_init::testPermuteAddrsList : elapsed 0 : OK > Zookeeper_close::testIOThreadStoppedOnExpire : assertion : elapsed 1056 > Zookeeper_close::testCloseUnconnected : elapsed 0 : OK > Zookeeper_close::testCloseUnconnected1 : elapsed 91 : OK > Zookeeper_close::testCloseConnected1 : assertion : elapsed 1056 > Zookeeper_close::testCloseFromWatcher1 : assertion : elapsed 1076 > Zookeeper_simpleSystem::testAsyncWatcherAutoReset ZooKeeper server started : > elapsed 12155 : OK > Zookeeper_simpleSystem::testDeserializeString : elapsed 0 : OK > Zookeeper_simpleSystem::testNullData : elapsed 1031 : OK > Zookeeper_simpleSystem::testIPV6 : elapsed 1005 : OK > Zookeeper_simpleSystem::testPath : elapsed 1024 : OK > Zookeeper_simpleSystem::testPathValidation : elapsed 1053 : OK > Zookeeper_simpleSystem::testPing : elapsed 17287 : OK > Zookeeper_simpleSystem::testAcl : elapsed 1019 : OK > Zookeeper_simpleSystem::testChroot : elapsed 3052 : OK > Zookeeper_simpleSystem::testAuth : assertion : elapsed 7010 > Zookeeper_simpleSystem::testHangingClient : elapsed 1015 : OK > Zookeeper_simpleSystem::testWatcherAutoResetWithGlobal ZooKeeper server > started ZooKeeper server started ZooKeeper server started : elapsed 20556 : OK > Zookeeper_simpleSystem::testWatcherAutoResetWithLocal ZooKeeper server > started ZooKeeper server started ZooKeeper server started : elapsed 20563 : OK > Zookeeper_simpleSystem::testGetChildren2 : elapsed 1041 : OK > Zookeeper_multi::testCreate : elapsed 1017 : OK > Zookeeper_multi::testCreateDelete : elapsed 1007 : OK > Zookeeper_multi::testInvalidVersion : elapsed 1011 : OK > Zookeeper_multi::testNestedCreate : elapsed 1009 : OK > Zookeeper_multi::testSetData : elapsed 6019 : OK > Zookeeper_multi::testUpdateConflict : elapsed 1014 : OK > Zookeeper_multi::testDeleteUpdateConflict : elapsed 1007 : OK > Zookeeper_multi::testAsyncMulti : elapsed 2001 : OK > Zookeeper_multi::testMultiFail : elapsed 1006 : OK > Zookeeper_multi::testCheck : elapsed 1020 : OK > Zookeeper_multi::testWatch : elapsed 2013 : OK > Zookeeper_watchers::testDefaultSessionWatcher1zktest-mt: > tests/ZKMocks.cc:271: SyncedBoolCondition > DeliverWatchersWrapper::isDelivered() const: Assertion `i<1000' failed. > Aborted (core dumped) > It would appear that the zookeeper connection does not transition to > connected within the required time; I increased the time allowed but no > change. > Ubuntu raring has glibc 2.17; the test suite works fine on previous Ubuntu > releases and this is the only difference that stood out. > Interestingly the cli_mt worked just fine connecting to the same zookeeper > instance that the tests left lying around so I'm assuming this is a test > error rather than an actual bug. -- This message was sent by Atlassian JIRA (v6.1#
[jira] [Comment Edited] (ZOOKEEPER-1646) mt c client tests fail on Ubuntu Raring
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1646?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13791725#comment-13791725 ] Patrick Hunt edited comment on ZOOKEEPER-1646 at 10/10/13 5:49 PM: --- ZOOKEEPER-1646 is the same issue as my comment on ZOOKEEPER-1742 see: https://issues.apache.org/jira/browse/ZOOKEEPER-1742?focusedCommentId=13790629&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13790629 was (Author: phunt): ZOOKEEPER-1646 is the same issue as my comment on ZOOKEEPER-1742 > mt c client tests fail on Ubuntu Raring > --- > > Key: ZOOKEEPER-1646 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1646 > Project: ZooKeeper > Issue Type: Bug > Components: c client >Affects Versions: 3.4.5 > Environment: Ubuntu 13.04 (raring), glibc 2.17 >Reporter: James Page >Assignee: Patrick Hunt >Priority: Blocker > Fix For: 3.4.6 > > > Misc tests fail in the c client binding under the current Ubuntu development > release: > ./zktest-mt > ZooKeeper server startedRunning > Zookeeper_clientretry::testRetry ZooKeeper server started ZooKeeper server > started : elapsed 9315 : OK > Zookeeper_operations::testAsyncWatcher1 : assertion : elapsed 1054 > Zookeeper_operations::testAsyncGetOperation : assertion : elapsed 1055 > Zookeeper_operations::testOperationsAndDisconnectConcurrently1 : assertion : > elapsed 1066 > Zookeeper_operations::testOperationsAndDisconnectConcurrently2 : elapsed 0 : > OK > Zookeeper_operations::testConcurrentOperations1 : assertion : elapsed 1055 > Zookeeper_init::testBasic : elapsed 1 : OK > Zookeeper_init::testAddressResolution : elapsed 0 : OK > Zookeeper_init::testMultipleAddressResolution : elapsed 0 : OK > Zookeeper_init::testNullAddressString : elapsed 0 : OK > Zookeeper_init::testEmptyAddressString : elapsed 0 : OK > Zookeeper_init::testOneSpaceAddressString : elapsed 0 : OK > Zookeeper_init::testTwoSpacesAddressString : elapsed 0 : OK > Zookeeper_init::testInvalidAddressString1 : elapsed 0 : OK > Zookeeper_init::testInvalidAddressString2 : elapsed 175 : OK > Zookeeper_init::testNonexistentHost : elapsed 92 : OK > Zookeeper_init::testOutOfMemory_init : elapsed 0 : OK > Zookeeper_init::testOutOfMemory_getaddrs1 : elapsed 0 : OK > Zookeeper_init::testOutOfMemory_getaddrs2 : elapsed 1 : OK > Zookeeper_init::testPermuteAddrsList : elapsed 0 : OK > Zookeeper_close::testIOThreadStoppedOnExpire : assertion : elapsed 1056 > Zookeeper_close::testCloseUnconnected : elapsed 0 : OK > Zookeeper_close::testCloseUnconnected1 : elapsed 91 : OK > Zookeeper_close::testCloseConnected1 : assertion : elapsed 1056 > Zookeeper_close::testCloseFromWatcher1 : assertion : elapsed 1076 > Zookeeper_simpleSystem::testAsyncWatcherAutoReset ZooKeeper server started : > elapsed 12155 : OK > Zookeeper_simpleSystem::testDeserializeString : elapsed 0 : OK > Zookeeper_simpleSystem::testNullData : elapsed 1031 : OK > Zookeeper_simpleSystem::testIPV6 : elapsed 1005 : OK > Zookeeper_simpleSystem::testPath : elapsed 1024 : OK > Zookeeper_simpleSystem::testPathValidation : elapsed 1053 : OK > Zookeeper_simpleSystem::testPing : elapsed 17287 : OK > Zookeeper_simpleSystem::testAcl : elapsed 1019 : OK > Zookeeper_simpleSystem::testChroot : elapsed 3052 : OK > Zookeeper_simpleSystem::testAuth : assertion : elapsed 7010 > Zookeeper_simpleSystem::testHangingClient : elapsed 1015 : OK > Zookeeper_simpleSystem::testWatcherAutoResetWithGlobal ZooKeeper server > started ZooKeeper server started ZooKeeper server started : elapsed 20556 : OK > Zookeeper_simpleSystem::testWatcherAutoResetWithLocal ZooKeeper server > started ZooKeeper server started ZooKeeper server started : elapsed 20563 : OK > Zookeeper_simpleSystem::testGetChildren2 : elapsed 1041 : OK > Zookeeper_multi::testCreate : elapsed 1017 : OK > Zookeeper_multi::testCreateDelete : elapsed 1007 : OK > Zookeeper_multi::testInvalidVersion : elapsed 1011 : OK > Zookeeper_multi::testNestedCreate : elapsed 1009 : OK > Zookeeper_multi::testSetData : elapsed 6019 : OK > Zookeeper_multi::testUpdateConflict : elapsed 1014 : OK > Zookeeper_multi::testDeleteUpdateConflict : elapsed 1007 : OK > Zookeeper_multi::testAsyncMulti : elapsed 2001 : OK > Zookeeper_multi::testMultiFail : elapsed 1006 : OK > Zookeeper_multi::testCheck : elapsed 1020 : OK > Zookeeper_multi::testWatch : elapsed 2013 : OK > Zookeeper_watchers::testDefaultSessionWatcher1zktest-mt: > tests/ZKMocks.cc:271: SyncedBoolCondition > DeliverWatchersWrapper::isDelivered() const: Assertion `i<1000' failed. > Aborted (core dumped) > It would appear that the zookeeper connection does not transition to > connected within the required time; I increased the time allowed but no > change. > Ubuntu raring has glibc 2.
[jira] [Resolved] (ZOOKEEPER-1668) “Memory leak” about permgen
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1668?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Hunt resolved ZOOKEEPER-1668. - Resolution: Not A Problem > “Memory leak” about permgen > --- > > Key: ZOOKEEPER-1668 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1668 > Project: ZooKeeper > Issue Type: Improvement > Components: jmx, server >Affects Versions: 3.3.5 >Reporter: tokoot > > For each connection, a ConnectionBean will be created to represent this > connection at finishSessionInit: > | ... > | jmxConnectionBean = new ConnectionBean(this, zk); > | MBeanRegistry.getInstance().register(jmxConnectionBean, zk.jmxServerBean); > || ... > || ObjectName oname = makeObjectName(path, bean); > ||| ... > ||| return new ObjectName(beanName.toString()); > ... > _canonicalName = (new String(canonical_chars, 0, prop_index)).intern(); > So, for every connection, it takes dozens of bytes at permgen. With > connection established constantly, the usage of permgen will increase > continuously. > Is it reasonable or necessary to manage each connection with ConnectionBean? -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (ZOOKEEPER-1736) Zookeeper SASL authentication allows anonymus users to log in
[
https://issues.apache.org/jira/browse/ZOOKEEPER-1736?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick Hunt resolved ZOOKEEPER-1736.
-
Resolution: Not A Problem
> Zookeeper SASL authentication allows anonymus users to log in
> -
>
> Key: ZOOKEEPER-1736
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1736
> Project: ZooKeeper
> Issue Type: Bug
> Components: server
> Environment: Development
>Reporter: AntonioS
>
> Hello.
> I have configured Zookeeper to provide SASL authentication, using ordinary
> username and password stored in the JAAS.conf as a DigestLoginModule
> I have created a simple jaas.conf file:
> Server {
> org.apache.zookeeper.server.auth.DigestLoginModule required
> user_admin="admin";
> };
> Client {
> org.apache.zookeeper.server.auth.DigestLoginModule required
> username="admin"
> password="admin";
> };
> I have the zoo.cfg correctly configured for security, adding the following:
> requireClientAuthScheme=sasl
> authProvider.1=org.apache.zookeeper.server.auth.SASLAuthenticationProvider
> jaasLoginRenew=360
> zookeeper.allowSaslFailedClients=false
> And I also have the java.env file:
> export
> JVMFLAGS="-Djava.security.auth.login.config=/etc/zookeeper/conf/jaas.conf
> -Dzookeeper.allowSaslFailedClients=false"
> Everything looks good. If I put the right username and password I
> authenticate, otherwise not and I get an exception.
> The problem is when I don’t put any username and password at all, zookeeper
> allows me to go through.
> I tried different things but nothing stops anonymous users to log in.
> I was looking at the source code, in particular the ZookeeperServer.java,
> this method:
> public void processPacket(ServerCnxn cnxn, ByteBuffer incomingBuffer)
> throws IOException {
> The section below:
> } else {
> if (h.getType() == OpCode.sasl) {
> Record rsp = processSasl(incomingBuffer,cnxn);
> ReplyHeader rh = new ReplyHeader(h.getXid(), 0,
> KeeperException.Code.OK.intValue());
> cnxn.sendResponse(rh,rsp, "response"); // not sure about 3rd
> arg..what is it?
> }
> else {
> Request si = new Request(cnxn, cnxn.getSessionId(),
> h.getXid(),
> h.getType(), incomingBuffer, cnxn.getAuthInfo());
> si.setOwner(ServerCnxn.me);
> submitRequest(si);
> }
> }
> The else flow appears to just forward any anonymous request to the handler,
> without attempting any authentication.
> Is this a bug? Is there any way to stop anonymous users connecting to
> Zookeeper?
> Thanks
> Antonio
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Updated] (ZOOKEEPER-1744) clientPortAddress breaks "zkServer.sh status"
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Hunt updated ZOOKEEPER-1744: Priority: Critical (was: Major) > clientPortAddress breaks "zkServer.sh status" > -- > > Key: ZOOKEEPER-1744 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1744 > Project: ZooKeeper > Issue Type: Bug > Components: scripts >Affects Versions: 3.4.5 >Reporter: Nick Ohanian >Assignee: Nick Ohanian >Priority: Critical > Fix For: 3.4.6, 3.5.0 > > Attachments: ZOOKEEPER-1744.patch > > > When "clientPortAddress" is used in the config file (zoo.cfg), zkServer.sh's > status command runs a grep command that matches both "clientPort" and > "clientPortAddress". This creates an extra argument for FourLetterWordMain, > which fails, so the status command incorrectly indicates that it couldn't > connect to the server. > Also, "localhost" is hardcoded as the target host for FourLetterWordMain. > The "clientPortAddress" should be used if it is provided in the config file. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (ZOOKEEPER-1744) clientPortAddress breaks "zkServer.sh status"
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Hunt updated ZOOKEEPER-1744: Assignee: Nick Ohanian > clientPortAddress breaks "zkServer.sh status" > -- > > Key: ZOOKEEPER-1744 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1744 > Project: ZooKeeper > Issue Type: Bug > Components: scripts >Affects Versions: 3.4.5 >Reporter: Nick Ohanian >Assignee: Nick Ohanian > Fix For: 3.4.6, 3.5.0 > > Attachments: ZOOKEEPER-1744.patch > > > When "clientPortAddress" is used in the config file (zoo.cfg), zkServer.sh's > status command runs a grep command that matches both "clientPort" and > "clientPortAddress". This creates an extra argument for FourLetterWordMain, > which fails, so the status command incorrectly indicates that it couldn't > connect to the server. > Also, "localhost" is hardcoded as the target host for FourLetterWordMain. > The "clientPortAddress" should be used if it is provided in the config file. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Assigned] (ZOOKEEPER-1752) Download area contains obsolete releases
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1752?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Hunt reassigned ZOOKEEPER-1752: --- Assignee: Patrick Hunt > Download area contains obsolete releases > > > Key: ZOOKEEPER-1752 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1752 > Project: ZooKeeper > Issue Type: Bug >Reporter: Sebb >Assignee: Patrick Hunt > > The download area under http://www.apache.org/dist/zookeeper/ contains > several superseded releases. > It is important that only the latest release of each currently maintained > product line is stored on the main ASF mirrors. Links to older releases can > be provided on download pages, but the links should be to the ASF archive > server http://archive.apache.org/dist/zookeeper/ > See http://www.apache.org/dev/release.html#when-to-archive -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (ZOOKEEPER-1768) Cluster fails election loop until the device is full
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13791720#comment-13791720 ] Patrick Hunt commented on ZOOKEEPER-1768: - [~fpj] something we need to consider for 3.4.6? > Cluster fails election loop until the device is full > > > Key: ZOOKEEPER-1768 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1768 > Project: ZooKeeper > Issue Type: Bug > Components: leaderElection >Affects Versions: 3.4.5 >Reporter: yuxin.yan > Attachments: zk_debug.log.2013-09-25.log, zoo.cfg > > > Hi, > I have a five nodes cluster versioned 3.4.5 and now i find one node is > offline. > Firstly i restart the node but i find that "Error contacting service. It is > probably not running." and i find that the node always elect the leader and > always sync the snapshot logs and the device will be full every ten mins. > so could someone help me？ i will put the log and zoo.cfg in the attachment. > Thanks all. > yyx, -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (ZOOKEEPER-1115) follower can not sync with leader
[
https://issues.apache.org/jira/browse/ZOOKEEPER-1115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13791719#comment-13791719
]
Patrick Hunt commented on ZOOKEEPER-1115:
-
[~fpj] thoughts? Should we close this?
> follower can not sync with leader
> -
>
> Key: ZOOKEEPER-1115
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1115
> Project: ZooKeeper
> Issue Type: Bug
> Components: quorum
>Affects Versions: 3.3.0, 3.3.3
> Environment: linux rhel 4, x64, java version 1.4.2
>Reporter: helei
>Priority: Critical
>
> there are 5 members in the quorum. one follower can not sync with leader
> after restart. it seems leader has close the data connection with this
> follower because of read timeout. here is the key log in follower:
> {noformat}
> 2011-06-30 22:14:45,069 - WARN [Thread-17:QuorumCnxManager$RecvWorker@658] -
> Connection broken:
> java.nio.channels.ClosedChannelException
> at
> sun.nio.ch.SocketChannelImpl.ensureReadOpen(SocketChannelImpl.java:113)
> at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:156)
> at
> org.apache.zookeeper.server.quorum.QuorumCnxManager$RecvWorker.run(QuorumCnxManager.java:629)
> 2011-06-30 22:14:45,069 - INFO
> [QuorumPeer:/0.0.0.0:2181:FastLeaderElection@689] - Notification: 3,
> 17198470148, 3, 3, LOOKING, LOOKING, 3
> 2011-06-30 22:14:45,070 - ERROR [Thread-16:QuorumCnxManager$SendWorker@559] -
> Failed to send last message. Shutting down thread.
> java.nio.channels.ClosedChannelException
> at
> sun.nio.ch.SocketChannelImpl.ensureWriteOpen(SocketChannelImpl.java:126)
> at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:324)
> at
> org.apache.zookeeper.server.quorum.QuorumCnxManager$SendWorker.send(QuorumCnxManager.java:548)
> at
> org.apache.zookeeper.server.quorum.QuorumCnxManager$SendWorker.run(QuorumCnxManager.java:557)
> 2011-06-30 22:14:45,082 - INFO [QuorumPeer:/0.0.0.0:2181:Learner@282] -
> Getting a diff from the leader 0x4011bd462
> 2011-06-30 22:14:45,083 - WARN [Thread-18:QuorumCnxManager$SendWorker@589] -
> Send worker leaving thread
> 2011-06-30 22:14:45,085 - WARN [QuorumPeer:/0.0.0.0:2181:Follower@116] - Got
> zxid 0x4011bd405 expected 0x1
> 2011-06-30 22:14:45,090 - INFO [QuorumPeer:/0.0.0.0:2181:FileTxnSnapLog@208]
> - Snapshotting: 4011bd462
> 2011-06-30 22:14:53,397 - WARN [SyncThread:3:SendAckRequestProcessor@63] -
> Closing connection to leader, exception during packet send
> java.net.SocketException: Broken pipe
> at java.net.SocketOutputStream.socketWrite0(Native Method)
> at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92)
> at java.net.SocketOutputStream.write(SocketOutputStream.java:136)
> at
> java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:65)
> at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:123)
> at
> org.apache.zookeeper.server.quorum.Learner.writePacket(Learner.java:126)
> at
> org.apache.zookeeper.server.quorum.SendAckRequestProcessor.flush(SendAckRequestProcessor.java:61)
> at
> org.apache.zookeeper.server.SyncRequestProcessor.flush(SyncRequestProcessor.java:164)
> at
> org.apache.zookeeper.server.SyncRequestProcessor.run(SyncRequestProcessor.java:98)
> 2011-06-30 22:14:53,398 - WARN [QuorumPeer:/0.0.0.0:2181:Follower@82] -
> Exception when following the leader
> java.net.SocketException: Socket closed
> at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:99)
> at java.net.SocketOutputStream.write(SocketOutputStream.java:136)
> at
> java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:65)
> at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:123)
> at
> org.apache.zookeeper.server.quorum.Learner.writePacket(Learner.java:126)
> at org.apache.zookeeper.server.quorum.Learner.ping(Learner.java:358)
> at
> org.apache.zookeeper.server.quorum.Follower.processPacket(Follower.java:108)
> at
> org.apache.zookeeper.server.quorum.Follower.followLeader(Follower.java:79)
> at
> org.apache.zookeeper.server.quorum.QuorumPeer.run(QuorumPeer.java:634)
> 2011-06-30 22:14:53,398 - WARN [SyncThread:3:SendAckRequestProcessor@63] -
> Closing connection to leader, exception during packet send
> java.net.SocketException: Socket closed
> at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:99)
> at java.net.SocketOutputStream.write(SocketOutputStream.java:136)
> at
> java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:65)
> at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:123)
> at
> org.apache.zookeeper.server
[jira] [Updated] (ZOOKEEPER-536) the initial size of the hashsets for the watcher is too large
[ https://issues.apache.org/jira/browse/ZOOKEEPER-536?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Hunt updated ZOOKEEPER-536: --- Labels: newbie (was: ) > the initial size of the hashsets for the watcher is too large > - > > Key: ZOOKEEPER-536 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-536 > Project: ZooKeeper > Issue Type: Improvement >Reporter: Benjamin Reed > Labels: newbie > > setting a watches on a lot of different nodes can be expensive if there is > only one watch set on each node. by default the hashset we use to track > watches has 16 entries and takes up about 160 bytes. we should probably make > the initial size much lower. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (ZOOKEEPER-559) valgrind warnings running zkpython bindings
[ https://issues.apache.org/jira/browse/ZOOKEEPER-559?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Hunt updated ZOOKEEPER-559: --- Fix Version/s: (was: 3.5.0) > valgrind warnings running zkpython bindings > --- > > Key: ZOOKEEPER-559 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-559 > Project: ZooKeeper > Issue Type: Bug > Components: contrib-bindings >Affects Versions: 3.3.0 >Reporter: Patrick Hunt >Assignee: Lei Zhang > Attachments: valgrind-zk.tar.gz > > > I'm seeing some weird behavior running zk-latencies.py > http://github.com/phunt/zk-smoketest > don't know if it's related to zkbindings itself, but I ran valgrind to see if > it noticed any issues. see attached. > afaict these issues are related to zkpython binding, however I'm not sure. I > did run valgrind against the > zookeeper c library tests and these issues were not highlighted. So I'm > thinking this is zkpython errors, however > I'm not 100% sure. > Henry can you take a look? > -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (ZOOKEEPER-513) C client disconnect with stand-alone server abnormally
[ https://issues.apache.org/jira/browse/ZOOKEEPER-513?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Hunt resolved ZOOKEEPER-513. Resolution: Cannot Reproduce > C client disconnect with stand-alone server abnormally > -- > > Key: ZOOKEEPER-513 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-513 > Project: ZooKeeper > Issue Type: Bug > Components: c client >Affects Versions: 3.2.0 > Environment: Linux 2.6.9-52bs #2 SMP Fri Jan 26 13:34:38 CST 2007 > x86_64 x86_64 x86_64 GNU/Linux > Jdk: 1.6.0_14 >Reporter: Qian Ye > Fix For: 3.5.0 > > > The client which created an ephemeral node at the zookeeper server, printed > the following log > WARNING: 08-20 03:09:20: auto * 182894118176 > [logid:][reqip:][auto_exchanger_zk_basic.cpp:605]get children > fail.[/forum/elect_nodes][-7][operation timeout] > and the Zookeeper client printed the following log (the log level is INFO) > 2009-08-19 21:36:18,067:3813(0x9556c520):ZOO_INFO@log_env@545: Client > environment:zookeeper.version=zookeeper C client 3.2.0 > 606 2009-08-19 21:36:18,067:3813(0x9556c520):ZOO_INFO@log_env@549: Client > environment:host.name=jx-ziyuan-test00.jx.baidu.com > 607 2009-08-19 21:36:18,068:3813(0x9556c520):ZOO_INFO@log_env@557: Client > environments.name=Linux > 608 2009-08-19 21:36:18,068:3813(0x9556c520):ZOO_INFO@log_env@558: Client > environments.arch=2.6.9-52bs > 609 2009-08-19 21:36:18,068:3813(0x9556c520):ZOO_INFO@log_env@559: Client > environments.version=#2 SMP Fri Jan 26 13:34:38 CST 2007 > 610 2009-08-19 21:36:18,068:3813(0x9556c520):ZOO_INFO@log_env@567: Client > environment:user.name=club > 611 2009-08-19 21:36:18,068:3813(0x9556c520):ZOO_INFO@log_env@577: Client > environment:user.home=/home/club > 612 2009-08-19 21:36:18,068:3813(0x9556c520):ZOO_INFO@log_env@589: Client > environment:user.dir=/home/club/user/luhongbo/auto-exchanger > 613 2009-08-19 21:36:18,068:3813(0x9556c520):ZOO_INFO@zookeeper_init@613: > Initiating client connection, host=127.0.0.1:2181,127.0.0.1:2182 > sessionTimeout=2000 watcher=0x408c56 sessionId=0x0 > sessionPasswd= context=(nil) flags=0 > 614 2009-08-19 21:36:18,069:3813(0x41401960):ZOO_INFO@check_events@1439: > initiated connection to server [127.0.0.1:2181] > 615 2009-08-19 21:36:18,070:3813(0x41401960):ZOO_INFO@check_events@1484: > connected to server [127.0.0.1:2181] with session id=1232c1688a20093 > 616 2009-08-20 > 02:48:01,780:3813(0x41401960):ZOO_WARN@zookeeper_interest@1335: Exceeded > deadline by 520ms > 617 2009-08-20 > 03:08:52,332:3813(0x41401960):ZOO_WARN@zookeeper_interest@1335: Exceeded > deadline by 14ms > 618 2009-08-20 > 03:09:04,666:3813(0x41401960):ZOO_WARN@zookeeper_interest@1335: Exceeded > deadline by 48ms > 619 2009-08-20 > 03:09:09,733:3813(0x41401960):ZOO_WARN@zookeeper_interest@1335: Exceeded > deadline by 24ms > 620 2009-08-20 > 03:09:20,289:3813(0x41401960):ZOO_WARN@zookeeper_interest@1335: Exceeded > deadline by 264ms > 621 2009-08-20 > 03:09:20,295:3813(0x41401960):ZOO_ERROR@handle_socket_error_msg@1388: Socket > [127.0.0.1:2181] zk retcode=-7, errno=110(Connection timed out): conn > ection timed out (exceeded timeout by 264ms) > 622 2009-08-20 > 03:09:20,309:3813(0x41401960):ZOO_WARN@zookeeper_interest@1335: Exceeded > deadline by 284ms > 623 2009-08-20 > 03:09:20,309:3813(0x41401960):ZOO_ERROR@handle_socket_error_msg@1433: Socket > [127.0.0.1:2182] zk retcode=-4, errno=111(Connection refused): server > refused to accept the client > 624 2009-08-20 03:09:20,353:3813(0x41401960):ZOO_INFO@check_events@1439: > initiated connection to server [127.0.0.1:2181] > 625 2009-08-20 03:09:20,552:3813(0x41401960):ZOO_INFO@check_events@1484: > connected to server [127.0.0.1:2181] with session id=1232c1688a20093 > The problem happened at 03:09:20, it seems that the zookeeper refused to > accept the client, and I don't know why. > the zoo.cfg is like: > # The number of milliseconds of each tick > tickTime=500 > # The number of ticks that the initial > # synchronization phase can take > initLimit=10 > # The number of ticks that can pass between > # sending a request and getting an acknowledgement > syncLimit=5 > # the directory where the snapshot is stored. > dataDir=./data/ > # the port at which the clients will connect > clientPort=2181 > the C client used multi-thread library, and the session timeout is set to > 2000 when the zookeeper handler was initialized. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (ZOOKEEPER-559) valgrind warnings running zkpython bindings
[ https://issues.apache.org/jira/browse/ZOOKEEPER-559?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Hunt resolved ZOOKEEPER-559. Resolution: Duplicate Per request closing as a dup of ZOOKEEPER-559 > valgrind warnings running zkpython bindings > --- > > Key: ZOOKEEPER-559 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-559 > Project: ZooKeeper > Issue Type: Bug > Components: contrib-bindings >Affects Versions: 3.3.0 >Reporter: Patrick Hunt >Assignee: Lei Zhang > Fix For: 3.5.0 > > Attachments: valgrind-zk.tar.gz > > > I'm seeing some weird behavior running zk-latencies.py > http://github.com/phunt/zk-smoketest > don't know if it's related to zkbindings itself, but I ran valgrind to see if > it noticed any issues. see attached. > afaict these issues are related to zkpython binding, however I'm not sure. I > did run valgrind against the > zookeeper c library tests and these issues were not highlighted. So I'm > thinking this is zkpython errors, however > I'm not 100% sure. > Henry can you take a look? > -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (BOOKKEEPER-658) ledger cache refactor
[
https://issues.apache.org/jira/browse/BOOKKEEPER-658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13791708#comment-13791708
]
Hadoop QA commented on BOOKKEEPER-658:
--
Testing JIRA BOOKKEEPER-658
Patch
[0001-BOOKKEEPER-658-ledger-cache-refactor.patch|https://issues.apache.org/jira/secure/attachment/12607830/0001-BOOKKEEPER-658-ledger-cache-refactor.patch]
downloaded at Thu Oct 10 17:02:05 UTC 2013
{color:green}+1 PATCH_APPLIES{color}
{color:green}+1 CLEAN{color}
{color:green}+1 RAW_PATCH_ANALYSIS{color}
.{color:green}+1{color} the patch does not introduce any @author tags
.{color:green}+1{color} the patch does not introduce any tabs
.{color:green}+1{color} the patch does not introduce any trailing spaces
.{color:green}+1{color} the patch does not introduce any line longer than
120
.{color:green}+1{color} the patch does adds/modifies 4 testcase(s)
{color:green}+1 RAT{color}
.{color:green}+1{color} the patch does not seem to introduce new RAT
warnings
{color:green}+1 JAVADOC{color}
.{color:green}+1{color} the patch does not seem to introduce new Javadoc
warnings
{color:green}+1 COMPILE{color}
.{color:green}+1{color} HEAD compiles
.{color:green}+1{color} patch compiles
.{color:green}+1{color} the patch does not seem to introduce new javac
warnings
{color:green}+1 FINDBUGS{color}
.{color:green}+1{color} the patch does not seem to introduce new Findbugs
warnings
{color:green}+1 TESTS{color}
.Tests run: 880
{color:green}+1 DISTRO{color}
.{color:green}+1{color} distro tarball builds with the patch
{color:green}*+1 Overall result, good!, no -1s*{color}
The full output of the test-patch run is available at
. https://builds.apache.org/job/bookkeeper-trunk-precommit-build/507/
> ledger cache refactor
> -
>
> Key: BOOKKEEPER-658
> URL: https://issues.apache.org/jira/browse/BOOKKEEPER-658
> Project: Bookkeeper
> Issue Type: Sub-task
> Components: bookkeeper-server
>Reporter: Sijie Guo
>Assignee: Robin Dhamankar
> Fix For: 4.3.0
>
> Attachments: 0001-BOOKKEEPER-658-ledger-cache-refactor.patch,
> BOOKKEEPER-658.patch
>
>
> refactor ledger cache to separate in-memory page management from persistent
> management.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (ZOOKEEPER-1125) Intermittent java core test failures
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13791707#comment-13791707 ] Patrick Hunt commented on ZOOKEEPER-1125: - This still and issue with 3.4/trunk? Or should we close this? > Intermittent java core test failures > > > Key: ZOOKEEPER-1125 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1125 > Project: ZooKeeper > Issue Type: Bug >Reporter: Vishal Kher >Assignee: Vishal Kher > Fix For: 3.5.0 > > Attachments: fail_on_27th_iteration.log.gz, repeat-script.patch, > zk1125.log.gz, ZOOKEEPER-1125.patch > > > Some of the tests are consistently failing for me and intermittently on > hudson. > Posting discussion from mailing list below. > Vishal, > Can you please open a jira for this and mark it as a blocker for 3.4 > release? Looks like its transient: > https://builds.apache.org/job/ZooKeeper-trunk/ > The latest build is passing. > thanks > mahadev > - Hide quoted text - > On Mon, Jul 11, 2011 at 12:49 PM, Vishal Kher wrote: > > Hi, > > > > ant test-core-java is consistently failing for me. > > > > The error seems to be either: > > > > Testcase: testFollowersStartAfterLeader took 35.577 sec > >Caused an ERROR > > Did not connect > > java.util.concurrent.TimeoutException: Did not connect > >at > > org.apache.zookeeper.test.ClientBase$CountdownWatcher.waitForConnected(ClientBase.java:124) > >at > > org.apache.zookeeper.test.QuorumTest.testFollowersStartAfterLeader(QuorumTest.java:308) > >at > > org.apache.zookeeper.JUnit4ZKTestRunner$LoggedInvokeMethod.evaluate(JUnit4ZKTestRunner.java:52) > > > > or > > > > Testcase: testNoLogBeforeLeaderEstablishment took 8.831 sec > >Caused an ERROR > > KeeperErrorCode = ConnectionLoss for /blah > > org.apache.zookeeper.KeeperException$ConnectionLossException: > > KeeperErrorCode = ConnectionLoss for /blah > >at org.apache.zookeeper.KeeperException.create(KeeperException.java:99) > >at org.apache.zookeeper.KeeperException.create(KeeperException.java:51) > >at org.apache.zookeeper.ZooKeeper.create(ZooKeeper.java:761) > >at > > org.apache.zookeeper.test.QuorumTest.testNoLogBeforeLeaderEstablishment(QuorumTest.java:385) > >at > > org.apache.zookeeper.JUnit4ZKTestRunner$LoggedInvokeMethod.evaluate(JUnit4ZKTestRunner.java:52) > > > > Looks like the reason why the tests are failing for me is similar to why the > > tests failed on hudson: > > > > 2011-07-11 14:47:26,219 [myid:] - INFO [QuorumPeer[myid=2]/0.0.0.0:11379 > > :Leader@425] - Shutdown called > > java.lang.Exception: shutdown Leader! reason: Only 0 followers, need 1 > >at org.apache.zookeeper.server.quorum.Leader.shutdown(Leader.java:425) > >at org.apache.zookeeper.server.quorum.Leader.lead(Leader.java:400) > >at > > org.apache.zookeeper.server.quorum.QuorumPeer.run(QuorumPeer.java:729) > > 2011-07-11 14:47:26,220 [myid:] - INFO [QuorumPeer[myid=2]/0.0.0.0:11379 > > :ZooKeeperServer@416] - shutting down > > > > The leader is not able to ping the followers. Has anyone seen this before? > > > > Thanks. > > -Vishal > > > > On Sun, Jul 10, 2011 at 6:52 AM, Apache Jenkins Server < > > jenk...@builds.apache.org> wrote: > > > >> See https://builds.apache.org/job/ZooKeeper-trunk/1239/ > >> > >> > >> ### > >> ## LAST 60 LINES OF THE CONSOLE > >> ### > >> [...truncated 242795 lines...] > >>[junit] 2011-07-10 10:57:16,673 [myid:] - INFO > >> [main:SessionTrackerImpl@206] - Shutting down > >>[junit] 2011-07-10 10:57:16,673 [myid:] - INFO > >> [main:PrepRequestProcessor@702] - Shutting down > >>[junit] 2011-07-10 10:57:16,674 [myid:] - INFO > >> [main:SyncRequestProcessor@170] - Shutting down > >>[junit] 2011-07-10 10:57:16,674 [myid:] - INFO > >> [SyncThread:0:SyncRequestProcessor@152] - SyncRequestProcessor exited! > >>[junit] 2011-07-10 10:57:16,675 [myid:] - INFO > >> [main:FinalRequestProcessor@423] - shutdown of request processor complete > >>[junit] 2011-07-10 10:57:16,674 [myid:] - INFO [ProcessThread(sid:0 > >> cport:-1)::PrepRequestProcessor@133] - PrepRequestProcessor exited loop! > >>[junit] 2011-07-10 10:57:16,676 [myid:] - INFO [main:ClientBase@227] - > >> connecting to 127.0.0.1 11221 > >>[junit] ensureOnly:[] > >>[junit] 2011-07-10 10:57:16,677 [myid:] - INFO [main:ClientBase@428] - > >> STARTING server > >>[junit] 2011-07-10 10:57:16,678 [myid:] - INFO > >> [main:ZooKeeperServer@164] - Created server with tickTime 3000 > >> minSessionTimeout 6000 maxSessionTimeout 6 datadir > >> /grid/0/hudson/hudson-slave/workspace/ZooKeeper-trunk/trunk/build/test/tmp/test1139867753736175617.junit.dir/version-2 > >> s
[jira] [Updated] (ZOOKEEPER-1057) zookeeper c-client, connection to offline server fails to successfully fallback to second zk host
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1057?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Hunt updated ZOOKEEPER-1057: Priority: Critical (was: Major) Fix Version/s: 3.4.6 Is this still and issue? Sounds pretty serious. > zookeeper c-client, connection to offline server fails to successfully > fallback to second zk host > - > > Key: ZOOKEEPER-1057 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1057 > Project: ZooKeeper > Issue Type: Bug > Components: c client >Affects Versions: 3.3.1, 3.3.2, 3.3.3 > Environment: snowdutyrise-lm ~/-> uname -a > Darwin snowdutyrise-lm 9.8.0 Darwin Kernel Version 9.8.0: Wed Jul 15 16:55:01 > PDT 2009; root:xnu-1228.15.4~1/RELEASE_I386 i386 > also observed on: > 2.6.35-28-server 49-Ubuntu SMP Tue Mar 1 14:55:37 UTC 2011 >Reporter: Woody Anderson >Priority: Critical > Fix For: 3.4.6, 3.5.0 > > > Hello, I'm a contributor for the node.js zookeeper module: > https://github.com/yfinkelstein/node-zookeeper > i'm using zk 3.3.3 for the purposes of this issue, but i have validated it > fails on 3.3.1 and 3.3.2 > i'm having an issue when trying to connect when one of my zookeeper servers > is offline. > if the first server attempted is online, all is good. > if the offline server is attempted first, then the client is never able to > connect to _any_ server. > inside zookeeper.c a connection loss (-4) is received, the socket is closed > and buffers are cleaned up, it then attempts the next server in the list, > creates a new socket (which gets the same fd as the previously closed socket) > and connecting fails, and it continues to fail seemingly forever. > The nature of this "fail" is not that it gets -4 connection loss errors, but > that zookeeper_interest doesn't find anything going on on the socket before > the user provided timeout kicks things out. I don't want to have to wait 5 > minutes, even if i could make myself. > this is the message that follows the connection loss: > 2011-04-27 23:18:28,355:13485:ZOO_ERROR@handle_socket_error_msg@1530: Socket > [127.0.0.1:5020] zk retcode=-7, errno=60(Operation timed out): connection > timed out (exceeded timeout by 3ms) > 2011-04-27 23:18:28,355:13485:ZOO_ERROR@yield@213: yield:zookeeper_interest > returned error: -7 - operation timeout > While investigating, i decided to comment out close(zh->fd) in handle_error > (zookeeper.c#1153) > now everything works (obviously i'm leaking an fd). Connection the the second > host works immediately. > this is the behavior i'm looking for, though i clearly don't want to leak the > fd, so i'm wondering why the fd re-use is causing this issue. > close() is not returning an error (i checked even though current code assumes > success). > i'm on osx 10.6.7 > i tried adding a setsockopt so_linger (though i didn't want that to be a > solution), it didn't work. > full debug traces are included in issue here: > https://github.com/yfinkelstein/node-zookeeper/issues/6 -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Resolved] (ZOOKEEPER-1064) Startup script needs more LSB compatability
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1064?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Hunt resolved ZOOKEEPER-1064. - Resolution: Implemented Fix Version/s: (was: 3.5.0) based on the comments this is resolved by ZOOKEEPER-999 > Startup script needs more LSB compatability > --- > > Key: ZOOKEEPER-1064 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1064 > Project: ZooKeeper > Issue Type: Bug >Affects Versions: 3.3.2 >Reporter: Ted Dunning > > The zkServer.sh script kind of sort of implements the standard init.d style > of interaction. > It lacks > - nice return codes > - status method > - standard output messages > See > http://refspecs.freestandards.org/LSB_3.1.0/LSB-Core-generic/LSB-Core-generic/iniscrptact.html > and > http://refspecs.freestandards.org/LSB_3.1.0/LSB-Core-generic/LSB-Core-generic/iniscrptfunc.html > and > http://wiki.debian.org/LSBInitScripts > It is an open question how much zkServer should use these LSB scripts because > that may impair portability. I > think it should produce similar messages, however, and should return > standardized error codes. If lsb functions > are available, I think that they should be used so that ZK works as a first > class citizen. > I will produce a proposed patch. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (ZOOKEEPER-1066) Multi should have an async version
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Hunt updated ZOOKEEPER-1066: Component/s: (was: java client) Looks like ZOOKEEPER-1572 added Java (but not c) async multi. > Multi should have an async version > -- > > Key: ZOOKEEPER-1066 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1066 > Project: ZooKeeper > Issue Type: Bug > Components: c client >Reporter: Ted Dunning > > per the code review on ZOOKEEPER-965 it seems that multi should have an > asynchronous version. > The semantics should be essentially identical. The only difference is that > the original caller shouldn't wait for the result. Cloning existing > multi-operations should be a decent implementation strategy. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (ZOOKEEPER-1015) DateFormat.getDateTimeInstance() is very expensive, we can cache it to improve performance
[
https://issues.apache.org/jira/browse/ZOOKEEPER-1015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick Hunt updated ZOOKEEPER-1015:
Labels: newbie (was: )
> DateFormat.getDateTimeInstance() is very expensive, we can cache it to
> improve performance
> --
>
> Key: ZOOKEEPER-1015
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1015
> Project: ZooKeeper
> Issue Type: Bug
> Components: server
>Affects Versions: 3.3.2
>Reporter: Xiaoming Shi
> Labels: newbie
>
> In the file
> {noformat}
> ./zookeeper-3.3.2/src/java/main/org/apache/zookeeper/server/PurgeTxnLog.java
> line:103
> {noformat}
> DateFormat.getDateTimeInstance() is called many times in the for loop. We can
> cache the result and improve the performance
> This is similar to the Apache bug
> https://issues.apache.org/bugzilla/show_bug.cgi?id=48778
> Similar code can be found:
> {noformat}
> ./zookeeper-3.3.2/src/java/main/org/apache/zookeeper/server/TraceFormatter.java
> ./zookeeper-3.3.2/src/java/main/org/apache/zookeeper/server/LogFormatter.java
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (ZOOKEEPER-1624) PrepRequestProcessor abort multi-operation incorrectly
[
https://issues.apache.org/jira/browse/ZOOKEEPER-1624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13791635#comment-13791635
]
Flavio Junqueira commented on ZOOKEEPER-1624:
-
No objection on my end.
> PrepRequestProcessor abort multi-operation incorrectly
> --
>
> Key: ZOOKEEPER-1624
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1624
> Project: ZooKeeper
> Issue Type: Bug
> Components: server
>Reporter: Thawan Kooburat
>Assignee: Thawan Kooburat
>Priority: Critical
> Labels: zk-review
> Fix For: 3.4.6, 3.5.0
>
> Attachments: ZOOKEEPER-1624-3.4, ZOOKEEPER-1624.patch,
> ZOOKEEPER-1624.patch, ZOOKEEPER-1624.patch, ZOOKEEPER-1624.patch,
> ZOOKEEPER-1624.patch
>
>
> We found this issue when trying to issue multiple instances of the following
> multi-op concurrently
> multi {
> 1. create sequential node /a-
> 2. create node /b
> }
> The expected result is that only the first multi-op request should success
> and the rest of request should fail because /b is already exist
> However, the reported result is that the subsequence multi-op failed because
> of sequential node creation failed which is not possible.
> Below is the return code for each sub-op when issuing 3 instances of the
> above multi-op asynchronously
> 1. ZOK, ZOK
> 2. ZOK, ZNODEEXISTS,
> 3. ZNODEEXISTS, ZRUNTIMEINCONSISTENCY,
> When I added more debug log. The cause is that PrepRequestProcessor rollback
> outstandingChanges of the second multi-op incorrectly causing sequential node
> name generation to be incorrect. Below is the sequential node name generated
> by PrepRequestProcessor
> 1. create /a-0001
> 2. create /a-0003
> 3. create /a-0001
> The bug is getPendingChanges() method. In failed to copied ChangeRecord for
> the parent node ("/"). So rollbackPendingChanges() cannot restore the right
> previous change record of the parent node when aborting the second multi-op
> The impact of this bug is that sequential node creation on the same parent
> node may fail until the previous one is committed. I am not sure if there is
> other implication or not.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (ZOOKEEPER-1624) PrepRequestProcessor abort multi-operation incorrectly
[
https://issues.apache.org/jira/browse/ZOOKEEPER-1624?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13791632#comment-13791632
]
Camille Fournier commented on ZOOKEEPER-1624:
-
This patch just makes it apply to 3.4 and removes the Java test. If there are
no objections I'll check it in.
> PrepRequestProcessor abort multi-operation incorrectly
> --
>
> Key: ZOOKEEPER-1624
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1624
> Project: ZooKeeper
> Issue Type: Bug
> Components: server
>Reporter: Thawan Kooburat
>Assignee: Thawan Kooburat
>Priority: Critical
> Labels: zk-review
> Fix For: 3.4.6, 3.5.0
>
> Attachments: ZOOKEEPER-1624-3.4, ZOOKEEPER-1624.patch,
> ZOOKEEPER-1624.patch, ZOOKEEPER-1624.patch, ZOOKEEPER-1624.patch,
> ZOOKEEPER-1624.patch
>
>
> We found this issue when trying to issue multiple instances of the following
> multi-op concurrently
> multi {
> 1. create sequential node /a-
> 2. create node /b
> }
> The expected result is that only the first multi-op request should success
> and the rest of request should fail because /b is already exist
> However, the reported result is that the subsequence multi-op failed because
> of sequential node creation failed which is not possible.
> Below is the return code for each sub-op when issuing 3 instances of the
> above multi-op asynchronously
> 1. ZOK, ZOK
> 2. ZOK, ZNODEEXISTS,
> 3. ZNODEEXISTS, ZRUNTIMEINCONSISTENCY,
> When I added more debug log. The cause is that PrepRequestProcessor rollback
> outstandingChanges of the second multi-op incorrectly causing sequential node
> name generation to be incorrect. Below is the sequential node name generated
> by PrepRequestProcessor
> 1. create /a-0001
> 2. create /a-0003
> 3. create /a-0001
> The bug is getPendingChanges() method. In failed to copied ChangeRecord for
> the parent node ("/"). So rollbackPendingChanges() cannot restore the right
> previous change record of the parent node when aborting the second multi-op
> The impact of this bug is that sequential node creation on the same parent
> node may fail until the previous one is committed. I am not sure if there is
> other implication or not.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (ZOOKEEPER-442) need a way to remove watches that are no longer of interest
[ https://issues.apache.org/jira/browse/ZOOKEEPER-442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13791627#comment-13791627 ] Patrick Hunt commented on ZOOKEEPER-442: [~rakeshr] just to make sure I'm understanding correctly, the document you put together is based on the current approach/patch, is that right? Or are you suggesting a different implementation? (my quick perusal indicates the former but I want to make sure I'm not missing something) > need a way to remove watches that are no longer of interest > --- > > Key: ZOOKEEPER-442 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-442 > Project: ZooKeeper > Issue Type: New Feature >Reporter: Benjamin Reed >Assignee: Daniel Gómez Ferro >Priority: Critical > Fix For: 3.5.0 > > Attachments: Remove Watch API.pdf, ZOOKEEPER-442.patch, > ZOOKEEPER-442.patch, ZOOKEEPER-442.patch, ZOOKEEPER-442.patch, > ZOOKEEPER-442.patch, ZOOKEEPER-442.patch, ZOOKEEPER-442.patch > > > currently the only way a watch cleared is to trigger it. we need a way to > enumerate the outstanding watch objects, find watch events the objects are > watching for, and remove interests in an event. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (ZOOKEEPER-1558) Leader should not snapshot uncommitted state
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13791574#comment-13791574 ] Flavio Junqueira commented on ZOOKEEPER-1558: - I was actually thinking about removing that call to takeSnapshot() from the leader so that we don't have the syncLimit problem you're referring to. > Leader should not snapshot uncommitted state > > > Key: ZOOKEEPER-1558 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1558 > Project: ZooKeeper > Issue Type: Sub-task > Components: quorum >Affects Versions: 3.4.6 >Reporter: Flavio Junqueira >Assignee: Flavio Junqueira >Priority: Blocker > Fix For: 3.4.6 > > Attachments: ZOOKEEPER-1558.patch, ZOOKEEPER-1558.patch, > ZOOKEEPER-1558.patch, ZOOKEEPER-1558.patch, ZOOKEEPER-1558.patch > > > Leader currently takes a snapshot when it calls loadData in the beginning of > the lead() method. The loaded data, however, may contain uncommitted state. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (ZOOKEEPER-442) need a way to remove watches that are no longer of interest
[ https://issues.apache.org/jira/browse/ZOOKEEPER-442?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13791557#comment-13791557 ] Mahadev konar commented on ZOOKEEPER-442: - Thanks Rakesh. Good to see the initiative. Ill read through the doc and get back to you. > need a way to remove watches that are no longer of interest > --- > > Key: ZOOKEEPER-442 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-442 > Project: ZooKeeper > Issue Type: New Feature >Reporter: Benjamin Reed >Assignee: Daniel Gómez Ferro >Priority: Critical > Fix For: 3.5.0 > > Attachments: Remove Watch API.pdf, ZOOKEEPER-442.patch, > ZOOKEEPER-442.patch, ZOOKEEPER-442.patch, ZOOKEEPER-442.patch, > ZOOKEEPER-442.patch, ZOOKEEPER-442.patch, ZOOKEEPER-442.patch > > > currently the only way a watch cleared is to trigger it. we need a way to > enumerate the outstanding watch objects, find watch events the objects are > watching for, and remove interests in an event. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Updated] (ZOOKEEPER-442) need a way to remove watches that are no longer of interest
[ https://issues.apache.org/jira/browse/ZOOKEEPER-442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rakesh R updated ZOOKEEPER-442: --- Attachment: Remove Watch API.pdf Hi [~mahadev], [~fpj] Its an interesting feature and would like to take it up. I've gone through the discussion thread and just prepared a draft doc which will help me to move on. Could you please have a look, I'll try to understand more about the existing patch and review comments. > need a way to remove watches that are no longer of interest > --- > > Key: ZOOKEEPER-442 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-442 > Project: ZooKeeper > Issue Type: New Feature >Reporter: Benjamin Reed >Assignee: Daniel Gómez Ferro >Priority: Critical > Fix For: 3.5.0 > > Attachments: Remove Watch API.pdf, ZOOKEEPER-442.patch, > ZOOKEEPER-442.patch, ZOOKEEPER-442.patch, ZOOKEEPER-442.patch, > ZOOKEEPER-442.patch, ZOOKEEPER-442.patch, ZOOKEEPER-442.patch > > > currently the only way a watch cleared is to trigger it. we need a way to > enumerate the outstanding watch objects, find watch events the objects are > watching for, and remove interests in an event. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (ZOOKEEPER-1742) "make check" doesn't work on macos
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13791425#comment-13791425 ] Germán Blanco commented on ZOOKEEPER-1742: -- I will give it a try, it will take around a week though. The current test programs for the C API are linked to the same library that is part of the release, that is the library that is used for the client applications. In order for the test to work without the wrap option, one possibility would be to create a different library with just a few function names changed (those functions that are now *wrapped*) and use this library only for the test programs. If I find out how to link the test programs with the shared library version instead of the static library maybe that wouldn't be necessary. If anybody can tell me how to do that, please do. > "make check" doesn't work on macos > -- > > Key: ZOOKEEPER-1742 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1742 > Project: ZooKeeper > Issue Type: Bug >Reporter: Flavio Junqueira >Assignee: Benjamin Reed > Fix For: 3.4.6, 3.5.0 > > > There are two problems I have spotted when running "make check" with the C > client. First, it complains that the sleep call is not defined in two test > files: tests/ZooKeeperQuorumServer.cc and tests/TestReconfigServer.cc. > Including unistd.h works. The second problem is with linker options. It > complains that "--wrap" is not a valid. I'm not sure how to deal with this > one yet, since I'm not sure why we are using it. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (ZOOKEEPER-1627) Add org.apache.zookeeper.common to exported packages in OSGi MANIFEST headers
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13791407#comment-13791407 ] Hudson commented on ZOOKEEPER-1627: --- SUCCESS: Integrated in ZooKeeper-trunk #2084 (See [https://builds.apache.org/job/ZooKeeper-trunk/2084/]) ZOOKEEPER-1627. Add org.apache.zookeeper.common to exported packages in OSGi MANIFEST (Arnoud Glimmerveen via phunt) (phunt: http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1530809) * /zookeeper/trunk/CHANGES.txt * /zookeeper/trunk/build.xml > Add org.apache.zookeeper.common to exported packages in OSGi MANIFEST headers > - > > Key: ZOOKEEPER-1627 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1627 > Project: ZooKeeper > Issue Type: Improvement >Affects Versions: 3.4.5 > Environment: Java: 1.6.0_31 > OSGi environment: Karaf 2.3.0 >Reporter: Arnoud Glimmerveen >Assignee: Arnoud Glimmerveen > Fix For: 3.4.6, 3.5.0 > > Attachments: ZOOKEEPER-1627.patch, ZOOKEEPER-1627-trunk.patch > > > The utilities contained in the org.apache.zookeeper.common package are not > part of the exported packages in an OSGi environment, thus making them not > available to other bundles using ZooKeeper. > Propose to add the org.apache.zookeeper.common package to the Export-Package > MANIFEST header. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (ZOOKEEPER-1147) Add support for local sessions
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1147?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13791405#comment-13791405 ] Hudson commented on ZOOKEEPER-1147: --- SUCCESS: Integrated in ZooKeeper-trunk #2084 (See [https://builds.apache.org/job/ZooKeeper-trunk/2084/]) ZOOKEEPER-1147. Add support for local sessions (Jay Shrauner, thawan via thawan) (thawan: http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1530781) * /zookeeper/trunk/CHANGES.txt * /zookeeper/trunk/src/c/include/zookeeper.h * /zookeeper/trunk/src/java/main/org/apache/zookeeper/KeeperException.java * /zookeeper/trunk/src/java/main/org/apache/zookeeper/cli/CreateCommand.java * /zookeeper/trunk/src/java/main/org/apache/zookeeper/server/FinalRequestProcessor.java * /zookeeper/trunk/src/java/main/org/apache/zookeeper/server/PrepRequestProcessor.java * /zookeeper/trunk/src/java/main/org/apache/zookeeper/server/Request.java * /zookeeper/trunk/src/java/main/org/apache/zookeeper/server/SessionTracker.java * /zookeeper/trunk/src/java/main/org/apache/zookeeper/server/SessionTrackerImpl.java * /zookeeper/trunk/src/java/main/org/apache/zookeeper/server/TraceFormatter.java * /zookeeper/trunk/src/java/main/org/apache/zookeeper/server/ZooKeeperServer.java * /zookeeper/trunk/src/java/main/org/apache/zookeeper/server/quorum/CommitProcessor.java * /zookeeper/trunk/src/java/main/org/apache/zookeeper/server/quorum/FollowerRequestProcessor.java * /zookeeper/trunk/src/java/main/org/apache/zookeeper/server/quorum/LeaderRequestProcessor.java * /zookeeper/trunk/src/java/main/org/apache/zookeeper/server/quorum/LeaderSessionTracker.java * /zookeeper/trunk/src/java/main/org/apache/zookeeper/server/quorum/LeaderZooKeeperServer.java * /zookeeper/trunk/src/java/main/org/apache/zookeeper/server/quorum/Learner.java * /zookeeper/trunk/src/java/main/org/apache/zookeeper/server/quorum/LearnerHandler.java * /zookeeper/trunk/src/java/main/org/apache/zookeeper/server/quorum/LearnerSessionTracker.java * /zookeeper/trunk/src/java/main/org/apache/zookeeper/server/quorum/LearnerZooKeeperServer.java * /zookeeper/trunk/src/java/main/org/apache/zookeeper/server/quorum/LocalSessionTracker.java * /zookeeper/trunk/src/java/main/org/apache/zookeeper/server/quorum/ObserverRequestProcessor.java * /zookeeper/trunk/src/java/main/org/apache/zookeeper/server/quorum/ProposalRequestProcessor.java * /zookeeper/trunk/src/java/main/org/apache/zookeeper/server/quorum/QuorumPeer.java * /zookeeper/trunk/src/java/main/org/apache/zookeeper/server/quorum/QuorumPeerConfig.java * /zookeeper/trunk/src/java/main/org/apache/zookeeper/server/quorum/QuorumPeerMain.java * /zookeeper/trunk/src/java/main/org/apache/zookeeper/server/quorum/QuorumZooKeeperServer.java * /zookeeper/trunk/src/java/main/org/apache/zookeeper/server/quorum/ReadOnlyZooKeeperServer.java * /zookeeper/trunk/src/java/main/org/apache/zookeeper/server/quorum/UpgradeableSessionTracker.java * /zookeeper/trunk/src/java/test/org/apache/zookeeper/server/PrepRequestProcessorTest.java * /zookeeper/trunk/src/java/test/org/apache/zookeeper/server/quorum/QuorumPeerMainTest.java * /zookeeper/trunk/src/java/test/org/apache/zookeeper/test/DuplicateLocalSessionUpgradeTest.java * /zookeeper/trunk/src/java/test/org/apache/zookeeper/test/LeaderSessionTrackerTest.java * /zookeeper/trunk/src/java/test/org/apache/zookeeper/test/LocalSessionRequestTest.java * /zookeeper/trunk/src/java/test/org/apache/zookeeper/test/LocalSessionsOnlyTest.java * /zookeeper/trunk/src/java/test/org/apache/zookeeper/test/QuorumBase.java * /zookeeper/trunk/src/java/test/org/apache/zookeeper/test/QuorumTest.java * /zookeeper/trunk/src/java/test/org/apache/zookeeper/test/QuorumUtil.java * /zookeeper/trunk/src/java/test/org/apache/zookeeper/test/ReadOnlyModeTest.java * /zookeeper/trunk/src/java/test/org/apache/zookeeper/test/SessionTrackerCheckTest.java * /zookeeper/trunk/src/java/test/org/apache/zookeeper/test/SessionUpgradeTest.java > Add support for local sessions > -- > > Key: ZOOKEEPER-1147 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1147 > Project: ZooKeeper > Issue Type: Improvement > Components: server >Affects Versions: 3.3.3 >Reporter: Vishal Kathuria >Assignee: Thawan Kooburat > Labels: api-change, scaling > Fix For: 3.5.0 > > Attachments: ZOOKEEPER-1147.patch, ZOOKEEPER-1147.patch, > ZOOKEEPER-1147.patch, ZOOKEEPER-1147.patch, ZOOKEEPER-1147.patch, > ZOOKEEPER-1147.patch, ZOOKEEPER-1147.patch, ZOOKEEPER-1147.patch, > ZOOKEEPER-1147.patch > > Original Estimate: 840h > Remaining Estimate: 840h > > This improvement is in the bucket of making ZooKeeper work at a large scale. > We are planning on having about a 1 million clients connect to a ZooKeeper > ensemble through a set of 50-100 ob
[jira] [Commented] (ZOOKEEPER-1509) Please update documentation to reflect updated FreeBSD support.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13791406#comment-13791406 ] Hudson commented on ZOOKEEPER-1509: --- SUCCESS: Integrated in ZooKeeper-trunk #2084 (See [https://builds.apache.org/job/ZooKeeper-trunk/2084/]) ZOOKEEPER-1509. Please update documentation to reflect updated FreeBSD support (George Neville-Neil via phunt) (phunt: http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1530706) * /zookeeper/trunk/CHANGES.txt * /zookeeper/trunk/docs/index.pdf * /zookeeper/trunk/docs/javaExample.pdf * /zookeeper/trunk/docs/linkmap.pdf * /zookeeper/trunk/docs/recipes.pdf * /zookeeper/trunk/docs/releasenotes.pdf * /zookeeper/trunk/docs/zookeeperAdmin.html * /zookeeper/trunk/docs/zookeeperAdmin.pdf * /zookeeper/trunk/docs/zookeeperHierarchicalQuorums.pdf * /zookeeper/trunk/docs/zookeeperInternals.pdf * /zookeeper/trunk/docs/zookeeperJMX.pdf * /zookeeper/trunk/docs/zookeeperObservers.pdf * /zookeeper/trunk/docs/zookeeperOver.pdf * /zookeeper/trunk/docs/zookeeperProgrammers.pdf * /zookeeper/trunk/docs/zookeeperQuotas.pdf * /zookeeper/trunk/docs/zookeeperStarted.pdf * /zookeeper/trunk/docs/zookeeperTutorial.pdf * /zookeeper/trunk/src/docs/src/documentation/content/xdocs/zookeeperAdmin.xml > Please update documentation to reflect updated FreeBSD support. > --- > > Key: ZOOKEEPER-1509 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1509 > Project: ZooKeeper > Issue Type: Task >Affects Versions: 3.4.6, 3.5.0 >Reporter: George Neville-Neil >Assignee: George Neville-Neil > Labels: newbie > Fix For: 3.5.0 > > Attachments: signature.asc, ZOOKEEPER-1509.patch > > > I noticed on this page: > http://zookeeper.apache.org/doc/r3.3.3/zookeeperAdmin.html > that FreeBSD was listed as being supported only as a client due to a problem > with the JVM on FreeBSD. > As of Friday zookeeper is fully supported on FreeBSD, using openjdk version 7 > and I have created a port for it in our ports collection: > http://www.freshports.org/devel/zookeeper/ > The zookeeper port tracks the stable release at the moment and in the near > future to track the current release, as the plain zookeeper port tracks the > stable. > Please update your documentation to reflect this change in support. > Best, > George Neville-Neil > g...@freebsd.org -- This message was sent by Atlassian JIRA (v6.1#6144)
ZooKeeper-trunk-WinVS2008_java - Build # 568 - Still Failing
See https://builds.apache.org/job/ZooKeeper-trunk-WinVS2008_java/568/ ### ## LAST 60 LINES OF THE CONSOLE ### [...truncated 294172 lines...] [junit] 2013-10-10 11:26:24,431 [myid:] - INFO [main:FinalRequestProcessor@442] - shutdown of request processor complete [junit] 2013-10-10 11:26:24,531 [myid:] - INFO [main:FourLetterWordMain@43] - connecting to 127.0.0.1 11221 [junit] 2013-10-10 11:26:24,733 [myid:] - INFO [main-SendThread(127.0.0.1:11221):ClientCnxn$SendThread@1008] - Opening socket connection to server 127.0.0.1/127.0.0.1:11221. Will not attempt to authenticate using SASL (java.lang.SecurityException: Unable to locate a login configuration) [junit] 2013-10-10 11:26:25,528 [myid:] - INFO [main:JMXEnv@133] - ensureOnly:[] [junit] 2013-10-10 11:26:25,529 [myid:] - INFO [main:ClientBase@414] - STARTING server [junit] 2013-10-10 11:26:25,529 [myid:] - INFO [main:ZooKeeperServer@149] - Created server with tickTime 3000 minSessionTimeout 6000 maxSessionTimeout 6 datadir f:\hudson\hudson-slave\workspace\ZooKeeper-trunk-WinVS2008_java\trunk\build\test\tmp\test2779852585149870981.junit.dir\version-2 snapdir f:\hudson\hudson-slave\workspace\ZooKeeper-trunk-WinVS2008_java\trunk\build\test\tmp\test2779852585149870981.junit.dir\version-2 [junit] 2013-10-10 11:26:25,538 [myid:] - INFO [main:NIOServerCnxnFactory@670] - Configuring NIO connection handler with 10s sessionless connection timeout, 1 selector thread(s), 4 worker threads, and 64 kB direct buffers. [junit] 2013-10-10 11:26:25,539 [myid:] - INFO [main:NIOServerCnxnFactory@683] - binding to port 0.0.0.0/0.0.0.0:11221 [junit] 2013-10-10 11:26:25,541 [myid:] - INFO [main:FileSnap@83] - Reading snapshot f:\hudson\hudson-slave\workspace\ZooKeeper-trunk-WinVS2008_java\trunk\build\test\tmp\test2779852585149870981.junit.dir\version-2\snapshot.b [junit] 2013-10-10 11:26:25,544 [myid:] - INFO [main:FileTxnSnapLog@297] - Snapshotting: 0xb to f:\hudson\hudson-slave\workspace\ZooKeeper-trunk-WinVS2008_java\trunk\build\test\tmp\test2779852585149870981.junit.dir\version-2\snapshot.b [junit] 2013-10-10 11:26:25,545 [myid:] - INFO [main:FourLetterWordMain@43] - connecting to 127.0.0.1 11221 [junit] 2013-10-10 11:26:25,549 [myid:] - INFO [NIOServerCxnFactory.AcceptThread:0.0.0.0/0.0.0.0:11221:NIOServerCnxnFactory$AcceptThread@296] - Accepted socket connection from /127.0.0.1:49723 [junit] 2013-10-10 11:26:25,550 [myid:] - INFO [NIOWorkerThread-1:NIOServerCnxn@828] - Processing stat command from /127.0.0.1:49723 [junit] 2013-10-10 11:26:25,550 [myid:] - INFO [NIOWorkerThread-1:NIOServerCnxn$StatCommand@677] - Stat command output [junit] 2013-10-10 11:26:25,551 [myid:] - INFO [NIOWorkerThread-1:NIOServerCnxn@999] - Closed socket connection for client /127.0.0.1:49723 (no session established for client) [junit] 2013-10-10 11:26:25,648 [myid:] - INFO [main:JMXEnv@133] - ensureOnly:[InMemoryDataTree, StandaloneServer_port] [junit] 2013-10-10 11:26:25,649 [myid:] - INFO [main:JMXEnv@105] - expect:InMemoryDataTree [junit] 2013-10-10 11:26:25,650 [myid:] - INFO [main:JMXEnv@108] - found:InMemoryDataTree org.apache.ZooKeeperService:name0=StandaloneServer_port-1,name1=InMemoryDataTree [junit] 2013-10-10 11:26:25,650 [myid:] - INFO [main:JMXEnv@105] - expect:StandaloneServer_port [junit] 2013-10-10 11:26:25,650 [myid:] - INFO [main:JMXEnv@108] - found:StandaloneServer_port org.apache.ZooKeeperService:name0=StandaloneServer_port-1 [junit] 2013-10-10 11:26:25,732 [myid:] - INFO [NIOServerCxnFactory.AcceptThread:0.0.0.0/0.0.0.0:11221:NIOServerCnxnFactory$AcceptThread@296] - Accepted socket connection from /127.0.0.1:49718 [junit] 2013-10-10 11:26:25,748 [myid:] - INFO [main:JUnit4ZKTestRunner$LoggedInvokeMethod@57] - FINISHED TEST METHOD testQuota [junit] 2013-10-10 11:26:25,748 [myid:] - INFO [main:ClientBase@451] - tearDown starting [junit] 2013-10-10 11:26:25,732 [myid:] - INFO [main-SendThread(127.0.0.1:11221):ClientCnxn$SendThread@882] - Socket connection established to 127.0.0.1/127.0.0.1:11221, initiating session [junit] 2013-10-10 11:26:25,751 [myid:] - INFO [NIOWorkerThread-2:ZooKeeperServer@858] - Client attempting to renew session 0x141a1e72331 at /127.0.0.1:49718 [junit] 2013-10-10 11:26:25,752 [myid:] - INFO [NIOWorkerThread-2:ZooKeeperServer@604] - Established session 0x141a1e72331 with negotiated timeout 3 for client /127.0.0.1:49718 [junit] 2013-10-10 11:26:25,753 [myid:] - INFO [main-SendThread(127.0.0.1:11221):ClientCnxn$SendThread@1261] - Session establishment complete on server 127.0.0.1/127.0.0.1:11221, sessionid = 0x141a1e72331, negotiated timeout = 3 [junit] 2013-10-10 11:26:25,852 [myid:] - INFO [ProcessThread(sid:0 cport:-1
ZooKeeper-3.4-WinVS2008_java - Build # 320 - Still Failing
See https://builds.apache.org/job/ZooKeeper-3.4-WinVS2008_java/320/ ### ## LAST 60 LINES OF THE CONSOLE ### [...truncated 203899 lines...] [junit] 2013-10-10 11:06:05,096 [myid:] - INFO [main-EventThread:ClientCnxn$EventThread@509] - EventThread shut down [junit] 2013-10-10 11:06:05,173 [myid:] - INFO [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:11221:NIOServerCnxnFactory@224] - NIOServerCnxn factory exited run method [junit] 2013-10-10 11:06:05,174 [myid:] - INFO [main:ZooKeeperServer@443] - shutting down [junit] 2013-10-10 11:06:05,174 [myid:] - INFO [main:SessionTrackerImpl@225] - Shutting down [junit] 2013-10-10 11:06:05,274 [myid:] - INFO [main:PrepRequestProcessor@743] - Shutting down [junit] 2013-10-10 11:06:05,274 [myid:] - INFO [main:SyncRequestProcessor@190] - Shutting down [junit] 2013-10-10 11:06:05,274 [myid:] - INFO [ProcessThread(sid:0 cport:-1)::PrepRequestProcessor@143] - PrepRequestProcessor exited loop! [junit] 2013-10-10 11:06:05,274 [myid:] - INFO [SyncThread:0:SyncRequestProcessor@168] - SyncRequestProcessor exited! [junit] 2013-10-10 11:06:05,274 [myid:] - INFO [main:FinalRequestProcessor@415] - shutdown of request processor complete [junit] 2013-10-10 11:06:05,374 [myid:] - INFO [main:FourLetterWordMain@43] - connecting to 127.0.0.1 11221 [junit] 2013-10-10 11:06:06,000 [myid:] - INFO [SessionTracker:SessionTrackerImpl@162] - SessionTrackerImpl exited loop! [junit] 2013-10-10 11:06:06,000 [myid:] - INFO [SessionTracker:SessionTrackerImpl@162] - SessionTrackerImpl exited loop! [junit] 2013-10-10 11:06:06,374 [myid:] - INFO [main:JMXEnv@133] - ensureOnly:[] [junit] 2013-10-10 11:06:06,388 [myid:] - INFO [main:ZKTestCase$1@65] - FAILED testQuota [junit] junit.framework.AssertionFailedError: expected:<0> but was:<1> [junit] at junit.framework.Assert.fail(Assert.java:47) [junit] at junit.framework.Assert.failNotEquals(Assert.java:283) [junit] at junit.framework.Assert.assertEquals(Assert.java:64) [junit] at junit.framework.Assert.assertEquals(Assert.java:195) [junit] at junit.framework.Assert.assertEquals(Assert.java:201) [junit] at org.apache.zookeeper.test.JMXEnv.ensureOnly(JMXEnv.java:138) [junit] at org.apache.zookeeper.test.ClientBase.startServer(ClientBase.java:417) [junit] at org.apache.zookeeper.test.ZooKeeperQuotaTest.testQuota(ZooKeeperQuotaTest.java:78) [junit] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [junit] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [junit] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [junit] at java.lang.reflect.Method.invoke(Method.java:597) [junit] at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44) [junit] at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) [junit] at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41) [junit] at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20) [junit] at org.apache.zookeeper.JUnit4ZKTestRunner$LoggedInvokeMethod.evaluate(JUnit4ZKTestRunner.java:52) [junit] at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28) [junit] at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31) [junit] at org.junit.rules.TestWatchman$1.evaluate(TestWatchman.java:48) [junit] at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:76) [junit] at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50) [junit] at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193) [junit] at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52) [junit] at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191) [junit] at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42) [junit] at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184) [junit] at org.junit.runners.ParentRunner.run(ParentRunner.java:236) [junit] at junit.framework.JUnit4TestAdapter.run(JUnit4TestAdapter.java:39) [junit] at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:518) [junit] at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.launch(JUnitTestRunner.java:1052) [junit] at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:906) [junit] 2013-10-10 11:06:06,481 [myid:] - INFO [main:ZKTestCase$1@55] - FINISHED testQuota [junit] Tests run:
[jira] [Commented] (ZOOKEEPER-1783) Distinguish initial configuration from first established configuration
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13791353#comment-13791353 ] Hadoop QA commented on ZOOKEEPER-1783: -- -1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12607771/ZOOKEEPER-1783-ver1.patch against trunk revision 1530809. +1 @author. The patch does not contain any @author tags. +1 tests included. The patch appears to include 3 new or modified tests. +1 javadoc. The javadoc tool did not generate any warning messages. +1 javac. The applied patch does not increase the total number of javac compiler warnings. +1 findbugs. The patch does not introduce any new Findbugs (version 1.3.9) warnings. +1 release audit. The applied patch does not increase the total number of release audit warnings. -1 core tests. The patch failed core unit tests. +1 contrib tests. The patch passed contrib unit tests. Test results: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1674//testReport/ Findbugs warnings: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1674//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html Console output: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1674//console This message is automatically generated. > Distinguish initial configuration from first established configuration > -- > > Key: ZOOKEEPER-1783 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1783 > Project: ZooKeeper > Issue Type: Bug > Components: quorum, server >Affects Versions: 3.5.0 >Reporter: Alexander Shraer >Assignee: Alexander Shraer > Fix For: 3.5.0 > > Attachments: ZOOKEEPER-1783.patch, ZOOKEEPER-1783-ver1.patch > > > We need a way to distinguish an initial config of a server and an initial > config of a running ensemble (before any reconfigs happen). Currently both > have version 0. > The version of a config increases with each reconfiguration, so the problem > is just with the initial config. -- This message was sent by Atlassian JIRA (v6.1#6144)
Failed: ZOOKEEPER-1783 PreCommit Build #1674
Jira: https://issues.apache.org/jira/browse/ZOOKEEPER-1783 Build: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1674/ ### ## LAST 60 LINES OF THE CONSOLE ### [...truncated 883665 lines...] [exec] [exec] [exec] [exec] -1 overall. Here are the results of testing the latest attachment [exec] http://issues.apache.org/jira/secure/attachment/12607771/ZOOKEEPER-1783-ver1.patch [exec] against trunk revision 1530809. [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 javadoc. The javadoc tool did not generate any warning messages. [exec] [exec] +1 javac. The applied patch does not increase the total number of javac compiler warnings. [exec] [exec] +1 findbugs. The patch does not introduce any new Findbugs (version 1.3.9) warnings. [exec] [exec] +1 release audit. The applied patch does not increase the total number of release audit warnings. [exec] [exec] -1 core tests. The patch failed core unit tests. [exec] [exec] +1 contrib tests. The patch passed contrib unit tests. [exec] [exec] Test results: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1674//testReport/ [exec] Findbugs warnings: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1674//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html [exec] Console output: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1674//console [exec] [exec] This message is automatically generated. [exec] [exec] [exec] == [exec] == [exec] Adding comment to Jira. [exec] == [exec] == [exec] [exec] [exec] Comment added. [exec] bb187bf014c2e79c71086b4d6dd19c3633fcdc71 logged out [exec] [exec] [exec] == [exec] == [exec] Finished build. [exec] == [exec] == [exec] [exec] BUILD FAILED /home/jenkins/jenkins-slave/workspace/PreCommit-ZOOKEEPER-Build/trunk/build.xml:1623: exec returned: 1 Total time: 43 minutes 17 seconds Build step 'Execute shell' marked build as failure Archiving artifacts Recording test results Description set: ZOOKEEPER-1783 Email was triggered for: Failure Sending email for trigger: Failure ### ## FAILED TESTS (if any) ## 5 tests failed. REGRESSION: org.apache.zookeeper.server.quorum.Zab1_0Test.testNormalRun Error Message: null Stack Trace: 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.quorum.QuorumPacket.deserialize(QuorumPacket.java:83) at org.apache.jute.BinaryInputArchive.readRecord(BinaryInputArchive.java:103) at org.apache.zookeeper.server.quorum.Zab1_0Test.readPacketSkippingPing(Zab1_0Test.java:320) at org.apache.zookeeper.server.quorum.Zab1_0Test$6.converseWithLeader(Zab1_0Test.java:893) at org.apache.zookeeper.server.quorum.Zab1_0Test.testLeaderConversation(Zab1_0Test.java:372) at org.apache.zookeeper.server.quorum.Zab1_0Test.testNormalRun(Zab1_0Test.java:855) REGRESSION: org.apache.zookeeper.server.quorum.Zab1_0Test.testTxnTimeout Error Message: null Stack Trace: 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.quorum.QuorumPacket.deserialize(QuorumPacket.java:83) at org.apache.jute.BinaryInputArchive.readRecord(BinaryInputArchive.java:103) at org.apache.zookeeper.server.quorum.Zab1_0Test.readPacketSkippingPing(Zab1_0Test.java:320) at org.apache.zookeeper.server.quorum.Zab1_0Test$7.converseWithLeader(Zab1_0Test.java:938) at org.apache.zookeeper.server.quorum.Zab1_0Test.testLeaderConversation(Zab1_0Test.java:372) at org.apache.zookeeper.server.quorum
[jira] [Commented] (ZOOKEEPER-1742) "make check" doesn't work on macos
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13791352#comment-13791352 ] Flavio Junqueira commented on ZOOKEEPER-1742: - [~abranzyck], do you think you can generate a patch? I'm also not sure what you mean with using a different version of the zookeeper library for the tests. > "make check" doesn't work on macos > -- > > Key: ZOOKEEPER-1742 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1742 > Project: ZooKeeper > Issue Type: Bug >Reporter: Flavio Junqueira >Assignee: Benjamin Reed > Fix For: 3.4.6, 3.5.0 > > > There are two problems I have spotted when running "make check" with the C > client. First, it complains that the sleep call is not defined in two test > files: tests/ZooKeeperQuorumServer.cc and tests/TestReconfigServer.cc. > Including unistd.h works. The second problem is with linker options. It > complains that "--wrap" is not a valid. I'm not sure how to deal with this > one yet, since I'm not sure why we are using it. -- This message was sent by Atlassian JIRA (v6.1#6144)
ZooKeeper-trunk-solaris - Build # 696 - Still Failing
See https://builds.apache.org/job/ZooKeeper-trunk-solaris/696/ ### ## LAST 60 LINES OF THE CONSOLE ### [...truncated 225694 lines...] [junit] 2013-10-10 09:08:43,928 [myid:] - INFO [NIOServerCxnFactory.SelectorThread-0:NIOServerCnxnFactory$SelectorThread@420] - selector thread exitted run method [junit] 2013-10-10 09:08:43,928 [myid:] - INFO [main:ZooKeeperServer@428] - shutting down [junit] 2013-10-10 09:08:43,929 [myid:] - INFO [main:SessionTrackerImpl@183] - Shutting down [junit] 2013-10-10 09:08:43,929 [myid:] - INFO [main:PrepRequestProcessor@953] - Shutting down [junit] 2013-10-10 09:08:43,929 [myid:] - INFO [main:SyncRequestProcessor@190] - Shutting down [junit] 2013-10-10 09:08:43,929 [myid:] - INFO [ProcessThread(sid:0 cport:-1)::PrepRequestProcessor@156] - PrepRequestProcessor exited loop! [junit] 2013-10-10 09:08:43,929 [myid:] - INFO [SyncThread:0:SyncRequestProcessor@168] - SyncRequestProcessor exited! [junit] 2013-10-10 09:08:43,929 [myid:] - INFO [main:FinalRequestProcessor@442] - shutdown of request processor complete [junit] 2013-10-10 09:08:43,930 [myid:] - INFO [main:FourLetterWordMain@43] - connecting to 127.0.0.1 11221 [junit] 2013-10-10 09:08:43,930 [myid:] - INFO [main:JMXEnv@133] - ensureOnly:[] [junit] 2013-10-10 09:08:43,931 [myid:] - INFO [main:ClientBase@414] - STARTING server [junit] 2013-10-10 09:08:43,931 [myid:] - INFO [main:ZooKeeperServer@149] - Created server with tickTime 3000 minSessionTimeout 6000 maxSessionTimeout 6 datadir /zonestorage/hudson_solaris/home/hudson/hudson-slave/workspace/ZooKeeper-trunk-solaris/trunk/build/test/tmp/test4255881276009834242.junit.dir/version-2 snapdir /zonestorage/hudson_solaris/home/hudson/hudson-slave/workspace/ZooKeeper-trunk-solaris/trunk/build/test/tmp/test4255881276009834242.junit.dir/version-2 [junit] 2013-10-10 09:08:43,932 [myid:] - INFO [main:NIOServerCnxnFactory@670] - Configuring NIO connection handler with 10s sessionless connection timeout, 2 selector thread(s), 16 worker threads, and 64 kB direct buffers. [junit] 2013-10-10 09:08:43,932 [myid:] - INFO [main:NIOServerCnxnFactory@683] - binding to port 0.0.0.0/0.0.0.0:11221 [junit] 2013-10-10 09:08:43,933 [myid:] - INFO [main:FileSnap@83] - Reading snapshot /zonestorage/hudson_solaris/home/hudson/hudson-slave/workspace/ZooKeeper-trunk-solaris/trunk/build/test/tmp/test4255881276009834242.junit.dir/version-2/snapshot.b [junit] 2013-10-10 09:08:43,936 [myid:] - INFO [main:FileTxnSnapLog@297] - Snapshotting: 0xb to /zonestorage/hudson_solaris/home/hudson/hudson-slave/workspace/ZooKeeper-trunk-solaris/trunk/build/test/tmp/test4255881276009834242.junit.dir/version-2/snapshot.b [junit] 2013-10-10 09:08:43,937 [myid:] - INFO [main:FourLetterWordMain@43] - connecting to 127.0.0.1 11221 [junit] 2013-10-10 09:08:43,937 [myid:] - INFO [NIOServerCxnFactory.AcceptThread:0.0.0.0/0.0.0.0:11221:NIOServerCnxnFactory$AcceptThread@296] - Accepted socket connection from /127.0.0.1:53258 [junit] 2013-10-10 09:08:43,938 [myid:] - INFO [NIOWorkerThread-1:NIOServerCnxn@828] - Processing stat command from /127.0.0.1:53258 [junit] 2013-10-10 09:08:43,938 [myid:] - INFO [NIOWorkerThread-1:NIOServerCnxn$StatCommand@677] - Stat command output [junit] 2013-10-10 09:08:43,939 [myid:] - INFO [NIOWorkerThread-1:NIOServerCnxn@999] - Closed socket connection for client /127.0.0.1:53258 (no session established for client) [junit] 2013-10-10 09:08:43,939 [myid:] - INFO [main:JMXEnv@133] - ensureOnly:[InMemoryDataTree, StandaloneServer_port] [junit] 2013-10-10 09:08:43,940 [myid:] - INFO [main:JMXEnv@105] - expect:InMemoryDataTree [junit] 2013-10-10 09:08:43,940 [myid:] - INFO [main:JMXEnv@108] - found:InMemoryDataTree org.apache.ZooKeeperService:name0=StandaloneServer_port-1,name1=InMemoryDataTree [junit] 2013-10-10 09:08:43,940 [myid:] - INFO [main:JMXEnv@105] - expect:StandaloneServer_port [junit] 2013-10-10 09:08:43,940 [myid:] - INFO [main:JMXEnv@108] - found:StandaloneServer_port org.apache.ZooKeeperService:name0=StandaloneServer_port-1 [junit] 2013-10-10 09:08:43,941 [myid:] - INFO [main:JUnit4ZKTestRunner$LoggedInvokeMethod@57] - FINISHED TEST METHOD testQuota [junit] 2013-10-10 09:08:43,941 [myid:] - INFO [main:ClientBase@451] - tearDown starting [junit] 2013-10-10 09:08:44,020 [myid:] - INFO [main:ZooKeeper@777] - Session: 0x141a1a00f66 closed [junit] 2013-10-10 09:08:44,020 [myid:] - INFO [main:ClientBase@421] - STOPPING server [junit] 2013-10-10 09:08:44,020 [myid:] - INFO [main-EventThread:ClientCnxn$EventThread@513] - EventThread shut down [junit] 2013-10-10 09:08:44,021 [myid:] - INFO [NIOServerCxnFactory.SelectorThread-0:NIOServerCnxnFactory$SelectorThread@420]
[jira] [Updated] (ZOOKEEPER-1783) Distinguish initial configuration from first established configuration
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1783?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Shraer updated ZOOKEEPER-1783: Attachment: ZOOKEEPER-1783-ver1.patch > Distinguish initial configuration from first established configuration > -- > > Key: ZOOKEEPER-1783 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1783 > Project: ZooKeeper > Issue Type: Bug > Components: quorum, server >Affects Versions: 3.5.0 >Reporter: Alexander Shraer >Assignee: Alexander Shraer > Fix For: 3.5.0 > > Attachments: ZOOKEEPER-1783.patch, ZOOKEEPER-1783-ver1.patch > > > We need a way to distinguish an initial config of a server and an initial > config of a running ensemble (before any reconfigs happen). Currently both > have version 0. > The version of a config increases with each reconfiguration, so the problem > is just with the initial config. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (ZOOKEEPER-1499) clientPort config changes not backwards-compatible
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1499?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13791270#comment-13791270 ] Hadoop QA commented on ZOOKEEPER-1499: -- +1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12607752/ZOOKEEPER-1499-ver3.patch against trunk revision 1530809. +1 @author. The patch does not contain any @author tags. +1 tests included. The patch appears to include 3 new or modified tests. +1 javadoc. The javadoc tool did not generate any warning messages. +1 javac. The applied patch does not increase the total number of javac compiler warnings. +1 findbugs. The patch does not introduce any new Findbugs (version 1.3.9) warnings. +1 release audit. The applied patch does not increase the total number of release audit warnings. +1 core tests. The patch passed core unit tests. +1 contrib tests. The patch passed contrib unit tests. Test results: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1673//testReport/ Findbugs warnings: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1673//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html Console output: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1673//console This message is automatically generated. > clientPort config changes not backwards-compatible > -- > > Key: ZOOKEEPER-1499 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1499 > Project: ZooKeeper > Issue Type: Bug > Components: server >Affects Versions: 3.5.0 >Reporter: Camille Fournier >Assignee: Alexander Shraer >Priority: Blocker > Fix For: 3.5.0 > > Attachments: ZOOKEEPER-1499.patch, ZOOKEEPER-1499-ver1.java, > ZOOKEEPER-1499-ver2.java, ZOOKEEPER-1499-ver3.patch > > > With the new reconfig logic, clientPort=2181 in the zoo.cfg file no longer > gets read, and clients can't connect without adding ;2181 to the end of their > server lines. -- This message was sent by Atlassian JIRA (v6.1#6144)
Success: ZOOKEEPER-1499 PreCommit Build #1673
Jira: https://issues.apache.org/jira/browse/ZOOKEEPER-1499 Build: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1673/ ### ## LAST 60 LINES OF THE CONSOLE ### [...truncated 311370 lines...] [exec] BUILD SUCCESSFUL [exec] Total time: 0 seconds [exec] [exec] [exec] [exec] [exec] +1 overall. Here are the results of testing the latest attachment [exec] http://issues.apache.org/jira/secure/attachment/12607752/ZOOKEEPER-1499-ver3.patch [exec] against trunk revision 1530809. [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 javadoc. The javadoc tool did not generate any warning messages. [exec] [exec] +1 javac. The applied patch does not increase the total number of javac compiler warnings. [exec] [exec] +1 findbugs. The patch does not introduce any new Findbugs (version 1.3.9) warnings. [exec] [exec] +1 release audit. The applied patch does not increase the total number of release audit warnings. [exec] [exec] +1 core tests. The patch passed core unit tests. [exec] [exec] +1 contrib tests. The patch passed contrib unit tests. [exec] [exec] Test results: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1673//testReport/ [exec] Findbugs warnings: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1673//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html [exec] Console output: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1673//console [exec] [exec] This message is automatically generated. [exec] [exec] [exec] == [exec] == [exec] Adding comment to Jira. [exec] == [exec] == [exec] [exec] [exec] Comment added. [exec] cfa7391dbb7401e655417b3b535688cb29220007 logged out [exec] [exec] [exec] == [exec] == [exec] Finished build. [exec] == [exec] == [exec] [exec] BUILD SUCCESSFUL Total time: 33 minutes 4 seconds Archiving artifacts Recording test results Description set: ZOOKEEPER-1499 Email was triggered for: Success Sending email for trigger: Success ### ## FAILED TESTS (if any) ## All tests passed
