[jira] Updated: (ZOOKEEPER-48) AUTH_ID not handled correctly when no auth ids are present
[ https://issues.apache.org/jira/browse/ZOOKEEPER-48?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Hunt updated ZOOKEEPER-48: -- Hadoop Flags: [Reviewed] AUTH_ID not handled correctly when no auth ids are present -- Key: ZOOKEEPER-48 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-48 Project: Zookeeper Issue Type: Bug Components: server Reporter: Benjamin Reed Assignee: Benjamin Reed Attachments: acl_4.patch AUTH_ID is used (usually done using Ids.CREATOR_ALL_ACL ) to represent the id that was used to authenticate with ZooKeeper. Thus, an exception should be raised if there are no authenticated ids present. Currently, the exception is not being raised. -- 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 ] Patrick Hunt updated ZOOKEEPER-2: - Status: Open (was: Patch Available) This patch fails ant test, specifically I see alot of the following in the log: Exception in thread QuorumPeer java.lang.NullPointerException at org.apache.zookeeper.server.quorum.QuorumPeer.run(QuorumPeer.java:397) (I ran the tests 3 times, failed each time in the same way, mainline test passes fine) This is ubuntu machine with java 1.6.0_06 (single cpu/core) 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 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 ] Patrick Hunt updated ZOOKEEPER-2: - Attachment: patch-le-polish I updated flavio's patch for the new directory structure on apache. 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 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-tabpanelfocusedCommentId=12618849#action_12618849 ] Patrick Hunt commented on ZOOKEEPER-2: -- PS, in future please use the id.patch naming scheme, ie. ZOOKEEPER-2.patch, thanks. 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 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-59) Synchronized block in NIOServerCnxn
[
https://issues.apache.org/jira/browse/ZOOKEEPER-59?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Flavio Paiva Junqueira updated ZOOKEEPER-59:
Attachment: (was: ZOOKEEPER-59.patch.patch)
Synchronized block in NIOServerCnxn
---
Key: ZOOKEEPER-59
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-59
Project: Zookeeper
Issue Type: Bug
Components: server
Reporter: Flavio Paiva Junqueira
Assignee: Flavio Paiva Junqueira
Attachments: ZOOKEEPER-59.patch
There are two synchronized blocks locking on different objects, and to me
they should be guarded by the same object. Here are the parts of the code I'm
talking about:
{noformat}
[EMAIL PROTECTED]
...
synchronized (this) {
outstandingRequests++;
// check throttling
if (zk.getInProcess() factory.outstandingLimit) {
disableRecv();
// following lines should not be needed since we are
already
// reading
// } else {
// enableRecv();
}
}
{noformat}
{noformat}
[EMAIL PROTECTED]
...
synchronized (this.factory) {
outstandingRequests--;
// check throttling
if (zk.getInProcess() factory.outstandingLimit
|| outstandingRequests 1) {
sk.selector().wakeup();
enableRecv();
}
}
{noformat}
I think the second one is correct, and the first synchronized block should be
guarded by this.factory.
This could be related to issue ZOOKEEPER-57, but I have no concrete
indication that this is the case so far.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-42) Change LE default to Fast TCP
[ https://issues.apache.org/jira/browse/ZOOKEEPER-42?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Hunt updated ZOOKEEPER-42: -- Hadoop Flags: [Reviewed] Change LE default to Fast TCP - Key: ZOOKEEPER-42 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-42 Project: Zookeeper Issue Type: Improvement Components: leaderElection Reporter: Patrick Hunt Assignee: Benjamin Reed Attachments: ZOOKEEPER-42.patch Moved from SourceForge to Apache. http://sourceforge.net/tracker/index.php?func=detailaid=1970356group_id=209147atid=1008546 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-104) KeptSet: a distributed data stucture backed by the children of a ZooKeeper node
[ https://issues.apache.org/jira/browse/ZOOKEEPER-104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12618884#action_12618884 ] Patrick Hunt commented on ZOOKEEPER-104: Committers/reviewers - be sure to give a strong indication when dispositioning a jira/patch. This will help both committers contributors and keep the process flowing smoothly: 1) indicate your vote (+/-1 or 0) and provide comment on general issues 2) if there are issues with a patch that need to be addressed before committing be sure to cancel the patch. Comments should indicate to the contributor what's expected to pass review. KeptSet: a distributed data stucture backed by the children of a ZooKeeper node --- Key: ZOOKEEPER-104 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-104 Project: Zookeeper Issue Type: New Feature Components: java client Reporter: Anthony Urso Assignee: Anthony Urso Priority: Minor Attachments: ZOOKEEPER-104.patch, ZOOKEEPER-104.patch, ZOOKEEPER-104.patch Here is an implementation of a ZooKeeper backed Java Set. It should be generally useful. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-104) KeptSet: a distributed data stucture backed by the children of a ZooKeeper node
[ https://issues.apache.org/jira/browse/ZOOKEEPER-104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12618903#action_12618903 ] Anthony Urso commented on ZOOKEEPER-104: The Set interface does not allow InterruptedException to be passed. I am OK with wrapping the InterruptedException in a RuntimeException and rethrowing it, but I think it violates the semantics of the InterruptedException. It's starting to look like this is not a suitable abstraction for ZooKeeper. KeptSet: a distributed data stucture backed by the children of a ZooKeeper node --- Key: ZOOKEEPER-104 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-104 Project: Zookeeper Issue Type: New Feature Components: java client Reporter: Anthony Urso Assignee: Anthony Urso Priority: Minor Attachments: ZOOKEEPER-104.patch, ZOOKEEPER-104.patch, ZOOKEEPER-104.patch Here is an implementation of a ZooKeeper backed Java Set. It should be generally useful. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (ZOOKEEPER-108) sync implementation reorders operations
sync implementation reorders operations --- Key: ZOOKEEPER-108 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-108 Project: Zookeeper Issue Type: Bug Components: server Reporter: Flavio Paiva Junqueira The current implementation of sync is broken. There is a race condition that causes a follower to return operations out of order, causing clients to drop their connections to a server. I'll be attaching a patch to fix this problem shortly. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
