[jira] Resolved: (ZOOKEEPER-54) remove sleeps in the tests.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-54?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Hunt resolved ZOOKEEPER-54. --- Resolution: Fixed Fix Version/s: 3.0.0 sleeps removed as part of ZOOKEEPER-111 patch > remove sleeps in the tests. > --- > > Key: ZOOKEEPER-54 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-54 > Project: Zookeeper > Issue Type: Bug > Components: tests >Affects Versions: 3.0.0 >Reporter: Mahadev konar >Assignee: Patrick Hunt > Fix For: 3.0.0 > > > remove the sleeps in the tests. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (ZOOKEEPER-61) Address (remove) use of sleep(#) in client/server test cases.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-61?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Hunt resolved ZOOKEEPER-61. --- Resolution: Fixed Fix Version/s: 3.0.0 sleeps removed as part of ZOOKEEPER-111 patch > Address (remove) use of sleep(#) in client/server test cases. > - > > Key: ZOOKEEPER-61 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-61 > Project: Zookeeper > Issue Type: Improvement > Components: tests >Reporter: Patrick Hunt >Assignee: Patrick Hunt > Fix For: 3.0.0 > > > Many of the java client/server test cases use "sleep(x)" during initial > rendezvous. This makes the tests slow, very brittle and they tend to fail > occasionally during CI (depending on load). In particular I've seen > QuorumTest exhibit this. > Would also be nice if we could extract the "base" client/server test > functionality to enable re-use and make test writing easier. I started this > with ClientBase in tests but could do a better job. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-110) Build script relies on svnant, which is not compatible with subversion 1.5 working copies
[ https://issues.apache.org/jira/browse/ZOOKEEPER-110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Hunt updated ZOOKEEPER-110: --- Fix Version/s: 3.0.0 > Build script relies on svnant, which is not compatible with subversion 1.5 > working copies > - > > Key: ZOOKEEPER-110 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-110 > Project: Zookeeper > Issue Type: Bug > Components: build >Affects Versions: 3.0.0 > Environment: Subversion 1.5 command line, or subclipse version 1.4.x >Reporter: Jakob Homan >Assignee: Jakob Homan > Fix For: 3.0.0 > > Attachments: ZOOKEEPER-110.patch, ZOOKEEPER-110.patch, > ZOOKEEPER-110.patch, ZOOKEEPER-110.patch > > > The current build.xml ant script uses svnant to obtain the latest revision > number from the repo, however svnant is not compatible with subversion 1.5 > (http://subversion.tigris.org/svn_1.5_releasenotes.html), and so the build > fails with working copies checked out by this version. The build fails with > "this version of subversion is too old, please get a newer version..." This > will become more apparent as svn 1.5 trickles out; I'm using a brand new dev > environment with both subclipse 1.4 and svn 1.5 client, so I got bit rather > quickly. > Those with svn 1.5 can get the code from the trunk, but cannot do an ant > build. > svnant hasn't been updated in more than a year and appears to be dead, so it > may no longer be a viable tool for the ant build. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-115) Potential NPE in QuorumCnxManager
[
https://issues.apache.org/jira/browse/ZOOKEEPER-115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick Hunt updated ZOOKEEPER-115:
---
Status: Open (was: Patch Available)
I see a small discrepancy:
Can setThreads ever be called with a null channel? (s parameter) There is a
null check in setThreads that seems unnecessary. In toSend and
receiveConnection methods we are opening a new channel. In the Listener.run()
method we are doing an client = ss.accept() (may return null in certain
circumstances), then calling client.socket() with no check for null, then
passing client to setThreads. Should we remove the null check or is the accept
returns null not being handled properly?
> Potential NPE in QuorumCnxManager
> -
>
> Key: ZOOKEEPER-115
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-115
> Project: Zookeeper
> Issue Type: Bug
> Components: quorum
>Reporter: Patrick Hunt
>Assignee: Flavio Paiva Junqueira
> Attachments: ZOOKEEPER-115.patch
>
>
> Findbugs flagged this, notice that we are checking for null after using the
> reference.
>if (senderWorkerMap.get(s.socket().getInetAddress()) != null) {
> senderWorkerMap.get(s.socket().getInetAddress()).finish();
> }
> /*
> * Start new worker thread with a clean state.
> */
> if (s != null) {
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-2) Synchronization issues in QuorumPeer and FastLeader election
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mahadev konar updated ZOOKEEPER-2: -- Resolution: Fixed Fix Version/s: 3.0.0 Hadoop Flags: [Reviewed] Status: Resolved (was: Patch Available) I just committed this. Thanks Flavio. > Synchronization issues in QuorumPeer and FastLeader election > > > Key: ZOOKEEPER-2 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2 > Project: Zookeeper > Issue Type: Bug > Components: leaderElection >Reporter: Benjamin Reed >Assignee: Flavio Paiva Junqueira > Fix For: 3.0.0 > > Attachments: patch-le-polish, patch-le-polish, ZOOKEEPER-2.patch > > > There are a couple of cases of member variables that need to be marked > volatile or surrounded in a synchronization block. A couple of examples are: > * QuorumPeer state should be synchronous > * currentVote in QuorumPeer is marked volatile, but when it's members are > often accessed individually as if they were in an atomic unit. Such code > should be changed to get a reference to the currentVote and they access > members through that reference. > * It looks like logicalClock in FastLeaderElection should be volatile. It > should either be fixed or commented to explain why it doesn't need to be. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-2) Synchronization issues in QuorumPeer and FastLeader election
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12625513#action_12625513 ] Mahadev konar commented on ZOOKEEPER-2: --- +1 the patch looks good... and passes the tests as well... > Synchronization issues in QuorumPeer and FastLeader election > > > Key: ZOOKEEPER-2 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2 > Project: Zookeeper > Issue Type: Bug > Components: leaderElection >Reporter: Benjamin Reed >Assignee: Flavio Paiva Junqueira > Attachments: patch-le-polish, patch-le-polish, ZOOKEEPER-2.patch > > > There are a couple of cases of member variables that need to be marked > volatile or surrounded in a synchronization block. A couple of examples are: > * QuorumPeer state should be synchronous > * currentVote in QuorumPeer is marked volatile, but when it's members are > often accessed individually as if they were in an atomic unit. Such code > should be changed to get a reference to the currentVote and they access > members through that reference. > * It looks like logicalClock in FastLeaderElection should be volatile. It > should either be fixed or commented to explain why it doesn't need to be. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-119) Reserve ".zookeeper" node for server use.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mahadev konar updated ZOOKEEPER-119: Status: Open (was: Patch Available) cancelling patch to take care of review comments... > Reserve ".zookeeper" node for server use. > - > > Key: ZOOKEEPER-119 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-119 > Project: Zookeeper > Issue Type: New Feature > Components: server >Reporter: Patrick Hunt >Assignee: Jakob Homan > Attachments: ZOOKEEPER-119.patch > > > The server should not allow clients to create .zookeeper nodes in the node > hierarchy. These nodes should be reserved for zk future use, some ideas: > * /.zookeeper/proc > * /.zookeeper/stats > * /.zookeeper/... > * /.../.zookeeper/... (disallow both at root as well as child nodes) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-119) Reserve ".zookeeper" node for server use.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12625507#action_12625507 ] Mahadev konar commented on ZOOKEEPER-119: - review comments for the patch... the patch just looks for ends with signature which is wrong ... 1) anything like creating a node zookeeper/myname.zookeeper would return true 2) i dont htink .zookeeper should be reserved for all the nodes... just the root should be fine 3) I think we should just change .zookeeper to zookeeper so the only node that zookeeper owns would be /zookeeper and that would have all the stats and others. Creating a .zookeeper does not seem right since we dont plan hide it? or do we? > Reserve ".zookeeper" node for server use. > - > > Key: ZOOKEEPER-119 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-119 > Project: Zookeeper > Issue Type: New Feature > Components: server >Reporter: Patrick Hunt >Assignee: Jakob Homan > Attachments: ZOOKEEPER-119.patch > > > The server should not allow clients to create .zookeeper nodes in the node > hierarchy. These nodes should be reserved for zk future use, some ideas: > * /.zookeeper/proc > * /.zookeeper/stats > * /.zookeeper/... > * /.../.zookeeper/... (disallow both at root as well as child nodes) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-123) In two places, the wrong class is specified for the logger
[ https://issues.apache.org/jira/browse/ZOOKEEPER-123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mahadev konar updated ZOOKEEPER-123: Resolution: Fixed Fix Version/s: 3.0.0 Hadoop Flags: [Reviewed] Status: Resolved (was: Patch Available) I just committed this. Thanks Jakob. > In two places, the wrong class is specified for the logger > -- > > Key: ZOOKEEPER-123 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-123 > Project: Zookeeper > Issue Type: Bug > Components: java client, tests >Affects Versions: 3.0.0 >Reporter: Jakob Homan >Assignee: Jakob Homan >Priority: Minor > Fix For: 3.0.0 > > Attachments: ZOOKEEPER-123.patch > > > Copy and paste strikes again. In two logger instantiations, the wrong class > is passed to the constructor. In ClientTest.java and ClientCnxn.java -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-123) In two places, the wrong class is specified for the logger
[ https://issues.apache.org/jira/browse/ZOOKEEPER-123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12625442#action_12625442 ] Mahadev konar commented on ZOOKEEPER-123: - +1 .. the patch looks good . > In two places, the wrong class is specified for the logger > -- > > Key: ZOOKEEPER-123 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-123 > Project: Zookeeper > Issue Type: Bug > Components: java client, tests >Affects Versions: 3.0.0 >Reporter: Jakob Homan >Assignee: Jakob Homan >Priority: Minor > Attachments: ZOOKEEPER-123.patch > > > Copy and paste strikes again. In two logger instantiations, the wrong class > is passed to the constructor. In ClientTest.java and ClientCnxn.java -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (ZOOKEEPER-114) cleanup ugly event messages in zookeeper client
[
https://issues.apache.org/jira/browse/ZOOKEEPER-114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jakob Homan reassigned ZOOKEEPER-114:
-
Assignee: Jakob Homan
> cleanup ugly event messages in zookeeper client
> ---
>
> Key: ZOOKEEPER-114
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-114
> Project: Zookeeper
> Issue Type: Improvement
> Components: java client
>Reporter: Patrick Hunt
>Assignee: Jakob Homan
> Fix For: 3.0.0
>
>
> Cleanup the event messages output by the java command line client:
> The java client ZooKeeper.java has a process method in MyWatcher that prints
> raw event information to the console. Many new users find this confusing (esp
> since state changes have a null path).
> public void process(WatcherEvent event) {
> System.err.println(event.getPath() + ": " + event.getState() + "-"
> + event.getType());
> }
> If this is a state change we should print that, if it's an event we should
> print that (state change doesn't have a path). Somewhere in the message we
> should also indicate that the client received a watch notification from the
> server.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-2) Synchronization issues in QuorumPeer and FastLeader election
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Flavio Paiva Junqueira updated ZOOKEEPER-2: --- Attachment: (was: ZOOKEEPER-2.patch) > Synchronization issues in QuorumPeer and FastLeader election > > > Key: ZOOKEEPER-2 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2 > Project: Zookeeper > Issue Type: Bug > Components: leaderElection >Reporter: Benjamin Reed >Assignee: Flavio Paiva Junqueira > Attachments: patch-le-polish, patch-le-polish, ZOOKEEPER-2.patch > > > There are a couple of cases of member variables that need to be marked > volatile or surrounded in a synchronization block. A couple of examples are: > * QuorumPeer state should be synchronous > * currentVote in QuorumPeer is marked volatile, but when it's members are > often accessed individually as if they were in an atomic unit. Such code > should be changed to get a reference to the currentVote and they access > members through that reference. > * It looks like logicalClock in FastLeaderElection should be volatile. It > should either be fixed or commented to explain why it doesn't need to be. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-2) Synchronization issues in QuorumPeer and FastLeader election
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Flavio Paiva Junqueira updated ZOOKEEPER-2: --- Attachment: ZOOKEEPER-2.patch Added javadoc comments. > Synchronization issues in QuorumPeer and FastLeader election > > > Key: ZOOKEEPER-2 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2 > Project: Zookeeper > Issue Type: Bug > Components: leaderElection >Reporter: Benjamin Reed >Assignee: Flavio Paiva Junqueira > Attachments: patch-le-polish, patch-le-polish, ZOOKEEPER-2.patch > > > There are a couple of cases of member variables that need to be marked > volatile or surrounded in a synchronization block. A couple of examples are: > * QuorumPeer state should be synchronous > * currentVote in QuorumPeer is marked volatile, but when it's members are > often accessed individually as if they were in an atomic unit. Such code > should be changed to get a reference to the currentVote and they access > members through that reference. > * It looks like logicalClock in FastLeaderElection should be volatile. It > should either be fixed or commented to explain why it doesn't need to be. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Hudson build is back to normal: ZooKeeper-trunk #64
See http://hudson.zones.apache.org/hudson/job/ZooKeeper-trunk/64/changes
