[jira] Commented: (ZOOKEEPER-16) Need to do path validation
[ https://issues.apache.org/jira/browse/ZOOKEEPER-16?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12605385#action_12605385 ] Benjamin Reed commented on ZOOKEEPER-16: The following characters cannot be used because they don't display well (or render in confusing ways): * overlong encodings * \u (we use null terminated strings!) * \u0001-\u0019,\u00-\u009F. * '.' and '..' cannot be path elements. For example, the following would be invalid paths '/a/b/./c' and '/a/b/../c'. (This could result in confusion since ZooKeeper does not use relative references.) * The following characters are also not valid for use \ud800-\uf8ff, \ufff0-\u, \uXfffe-\uX (where X is 1 to e), \uf-\uf Any of these violations should result in an error, decoding should stop, and an exception thrown or error returned. Need to do path validation -- Key: ZOOKEEPER-16 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-16 Project: Zookeeper Issue Type: Bug Components: c client, java client, server Reporter: Patrick Hunt Assignee: Benjamin Reed Moved from SourceForge to Apache. http://sourceforge.net/tracker/index.php?func=detailaid=1963141group_id=209147atid=1008544 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (ZOOKEEPER-46) Clients should check the latencies to the various servers and try to connect to the servers with the lowest latencies first
Clients should check the latencies to the various servers and try to connect to the servers with the lowest latencies first --- Key: ZOOKEEPER-46 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-46 Project: Zookeeper Issue Type: Improvement Reporter: Benjamin Reed When ZooKeeper clients and servers are on the same LAN or in the same data center it really doesn't matter which ZooKeeper server they connect to. However, when the ZooKeeper cluster spans data centers, clients should try to connect to local servers first. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (ZOOKEEPER-49) SetACL does not work
SetACL does not work
Key: ZOOKEEPER-49
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-49
Project: Zookeeper
Issue Type: Bug
Components: server
Reporter: Benjamin Reed
As reported by Shane:
Still exploring the ACL stuff in Zookeeper. Tried using setACL for a
path but get InvalidACL error thrown looking at pRequest in
PrepRequestProcessor ... and in particular these lines ...
SetACLRequest setAclRequest = new SetACLRequest();
if (!fixupACL(request.authInfo,
setAclRequest.getAcl())) {
throw new KeeperException(Code.InvalidACL);
}
a new SetACLRequest will return a null when called in fixupACL
returning false and throwing the exception as far as I can see.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[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 ] Benjamin Reed updated ZOOKEEPER-48: --- Attachment: acl_3.patch Since the fix for this issue overlaps with ZOOKEEPER-49 and since the fix and test for ZOOKEEPER-49 are so trival, I've included them in this patch. 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 Attachments: acl-2.patch, acl_3.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] Resolved: (ZOOKEEPER-47) io thread still around after a EXPIRED_SESSION or AUTH_FAILED event is received
[ https://issues.apache.org/jira/browse/ZOOKEEPER-47?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Reed resolved ZOOKEEPER-47. Resolution: Invalid io thread still around after a EXPIRED_SESSION or AUTH_FAILED event is received --- Key: ZOOKEEPER-47 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-47 Project: Zookeeper Issue Type: Bug Components: c client Reporter: Benjamin Reed If a session expires, the zhandle_t becomes invalid and useless; however, the io thread keeps going. do_io in mt_adaptor.c needs to check the return code of zookeeper_interest and zookeeper_process and get out of the loop if the handle is invalid. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-38) headers (version+) in log/snap files
[ https://issues.apache.org/jira/browse/ZOOKEEPER-38?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12614540#action_12614540 ] Benjamin Reed commented on ZOOKEEPER-38: I really like how you pulled the code out of the scattered locations around the source tree. I wish you would have pulled them into a couple of classes rather than scattering them into new classes. It seems like it would be really nice to have a Snapshot class and a TxnLog class. I think classes like SerializeUtils, AsyncSnapshotPolicy, Util, FileLogWriter, FileLogProvider, FileDBInfo (perhaps others) could be pulled into these classes. I agree with Mahadev that the extra interfaces seem overkill for the simple requirements of this Jira. The provider classes are also overkill for this Jira. Perhaps in the future we may need something like that, but I'd rather wait for the need than try and foresee a solution now. Mahadev and I will take a crack at collapsing these classes down. headers (version+) in log/snap files Key: ZOOKEEPER-38 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-38 Project: Zookeeper Issue Type: New Feature Components: server Reporter: Patrick Hunt Assignee: Andrew Kornev Fix For: 3.0.0 Attachments: ZOOKEEPER-38.patch, ZOOKEEPER-38.patch, ZOOKEEPER-38.patch Moved from SourceForge to Apache. http://sourceforge.net/tracker/index.php?func=detailaid=1961767group_id=209147atid=1008547 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-83) Switch to using maven to build ZooKeeper
[ https://issues.apache.org/jira/browse/ZOOKEEPER-83?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12616139#action_12616139 ] Benjamin Reed commented on ZOOKEEPER-83: I completely agreed with the goals you are expressing. Having ZooKeeper in the Maven repository is a good thing all the way around. The problem I have is supporting two different build tools. Granted we have a patch now, but going forward we would have to maintain (meaning fixing the build scripts and running the tests) both. I think that one build tool makes everyones life sane (er). I'm not familiar with most projects, but Hadoop (who we are a subproject of) doesn't use Maven. I talked to Owen about Hadoop using Maven and he mentioned they were looking at Ivy. I also see that there are Maven ant tasks from the Maven project that we can use. It seems to me that least disruptive way to get into the Maven repository is to use either the ant tasks or Ivy. Do you guys have an opinion on either of those two routes? Switch to using maven to build ZooKeeper Key: ZOOKEEPER-83 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-83 Project: Zookeeper Issue Type: Improvement Components: build Reporter: Hiram Chirino Assignee: Hiram Chirino Attachments: zookeeper-mavened.tgz Maven is a great too for building java projects at the ASF. It helps standardize the build a bit since it's a convention oriented. It's dependency auto downloading would remove the need to store the dependencies in svn, and it will handle many of the suggested ASF policies like gpg signing of the releases and such. The ZooKeeper build is almost vanilla except for the jute compiler bits. Things that would need to change are: * re-organize the source tree a little so that it uses the maven directory conventions * seperate the jute bits out into seperate modules so that a maven plugin can be with it -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-58) Race condition on ClientCnxn.java
[ https://issues.apache.org/jira/browse/ZOOKEEPER-58?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12616998#action_12616998 ] Benjamin Reed commented on ZOOKEEPER-58: +1 Race condition on ClientCnxn.java - Key: ZOOKEEPER-58 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-58 Project: Zookeeper Issue Type: Bug Components: java client Reporter: Flavio Paiva Junqueira Assignee: Benjamin Reed Attachments: ZOOKEEPER-58.patch There is a race condition involving the ByteByffer incomingBuffer, a field of ClientCnxn.SendThread. SendThread reads a packet in two steps: first it reads the length of the packet, followed by a read of the packet itself. Each of these steps corresponds to a call to doIO() from the main loop of run(). If there is an exception or the session times out, then it may leave incomingBuffer in an inconsistent state. The attached patch adds code to reset incomingBuffer upon a call to SendThread.cleanup(). This method is called upon an exception on run(). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-97) The code generators should support an optional output directory
[ https://issues.apache.org/jira/browse/ZOOKEEPER-97?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12617000#action_12617000 ] Benjamin Reed commented on ZOOKEEPER-97: One thing to keep in mind is that the jute generators in ZooKeeper really need to be replace with something like thrift, so we probably shouldn't put too much work into them. The code generators should support an optional output directory --- Key: ZOOKEEPER-97 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-97 Project: Zookeeper Issue Type: Improvement Reporter: Hiram Chirino Currently the code generators (jute compiler and version gen) generate code the current directory. If these tools are to be re-used by smart ides, ant tasks, or maven plugins, the output directory needs to be parameter to the tools. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-103) Reorganize the ZooKeeper source distro to follow maven conventions
[ https://issues.apache.org/jira/browse/ZOOKEEPER-103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Reed updated ZOOKEEPER-103: Status: Open (was: Patch Available) The hierachy implemented by this patch conflicts with ZOOKEEPER-80. Either the patch needs to accomodate the proposal in ZOOKEEPER-80, or ZOOKEEPER-80 needs to be updated with a new proposal. Reorganize the ZooKeeper source distro to follow maven conventions -- Key: ZOOKEEPER-103 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-103 Project: Zookeeper Issue Type: Improvement Components: build Reporter: Hiram Chirino Assignee: Hiram Chirino Fix For: 3.0.0 Attachments: ZOOKEEPER-103.patch, ZOOKEEPER-103.sh This was sugested as way to bridge the gap in ZOOKEEPER-83 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (ZOOKEEPER-32) CRCs for ZooKeeper data
[ https://issues.apache.org/jira/browse/ZOOKEEPER-32?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Reed reassigned ZOOKEEPER-32: -- Assignee: Mahadev konar (was: Benjamin Reed) CRCs for ZooKeeper data --- Key: ZOOKEEPER-32 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-32 Project: Zookeeper Issue Type: New Feature Components: server Reporter: Patrick Hunt Assignee: Mahadev konar Fix For: 3.0.0 Moved from SourceForge to Apache. http://sourceforge.net/tracker/index.php?func=detailaid=1945106group_id=209147atid=1008547 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (ZOOKEEPER-38) headers (version+) in log/snap files
[ https://issues.apache.org/jira/browse/ZOOKEEPER-38?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Reed reassigned ZOOKEEPER-38: -- Assignee: Mahadev konar (was: Benjamin Reed) Mahadev is simplifying the patch. headers (version+) in log/snap files Key: ZOOKEEPER-38 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-38 Project: Zookeeper Issue Type: New Feature Components: server Reporter: Patrick Hunt Assignee: Mahadev konar Fix For: 3.0.0 Attachments: ZOOKEEPER-38.patch, ZOOKEEPER-38.patch, ZOOKEEPER-38.patch Moved from SourceForge to Apache. http://sourceforge.net/tracker/index.php?func=detailaid=1961767group_id=209147atid=1008547 -- 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=12618399#action_12618399 ] Benjamin Reed commented on ZOOKEEPER-104: - InterruptedException is something we have to deal with from Java. We can't just catch them and retry. It is generally unsafe to eat this exception since it usually means someone wants the thread to go away. There seem to be a couple of ways to deal with InterruptedException but the safest seems to be to let it go through. 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-107) Allow dynamic changes to server cluster membership
[ https://issues.apache.org/jira/browse/ZOOKEEPER-107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12619035#action_12619035 ] Benjamin Reed commented on ZOOKEEPER-107: - +1 I like the idea. You can currently use DNS for this functionality: make zookeeper.acme.com resolve to 5 different IP addresses and then specify new ZooKeeper(zookeeper.acme.com:3233, 1000, this), but DNS is hard to modify. A replicate webserver would be much easier to update. Allow dynamic changes to server cluster membership -- Key: ZOOKEEPER-107 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-107 Project: Zookeeper Issue Type: Improvement Components: server Reporter: Patrick Hunt Currently cluster membership is statically defined, adding/removing hosts to/from the server cluster dynamically needs to be supported. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-63) Race condition in client close() operation
[ https://issues.apache.org/jira/browse/ZOOKEEPER-63?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Reed updated ZOOKEEPER-63: --- Attachment: patch_ZOOKEEPER-63.patch I've fixed the patch to not duplicate the logic in submitRequest Race condition in client close() operation -- Key: ZOOKEEPER-63 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-63 Project: Zookeeper Issue Type: Bug Components: java client Reporter: Patrick Hunt Assignee: james strachan Attachments: patch_ZOOKEEPER-63.patch, patch_ZOOKEEPER-63.patch There is a race condition in the java close operation on ZooKeeper.java. Client is sending a disconnect request to the server. Server will close any open connections with the client when it receives this. If the client has not yet shutdown it's subthreads (event/send threads for example) these threads may consider the condition an error. We see this alot in the tests where the clients output error logs because they are unaware that a disconnection has been requested by the client. Ben mentioned: perhaps we just have to change state to closed (on client) before sending disconnect request. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-63) Race condition in client close() operation
[ https://issues.apache.org/jira/browse/ZOOKEEPER-63?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Reed updated ZOOKEEPER-63: --- Status: Patch Available (was: Open) Race condition in client close() operation -- Key: ZOOKEEPER-63 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-63 Project: Zookeeper Issue Type: Bug Components: java client Reporter: Patrick Hunt Assignee: james strachan Attachments: patch_ZOOKEEPER-63.patch There is a race condition in the java close operation on ZooKeeper.java. Client is sending a disconnect request to the server. Server will close any open connections with the client when it receives this. If the client has not yet shutdown it's subthreads (event/send threads for example) these threads may consider the condition an error. We see this alot in the tests where the clients output error logs because they are unaware that a disconnection has been requested by the client. Ben mentioned: perhaps we just have to change state to closed (on client) before sending disconnect request. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-107) Allow dynamic changes to server cluster membership
[ https://issues.apache.org/jira/browse/ZOOKEEPER-107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12619109#action_12619109 ] Benjamin Reed commented on ZOOKEEPER-107: - I think there are two issues here: 1) adding/removing servers to a ZooKeeper cluster and 2) letting clients know about the change. We should probably separate them. I like the URL idea for dealing with 1) (especially when used in conjunction with the other idea in this Jira of defining a URL scheme for ZooKeeper). For 2) I agree with Hiram that it should be stored persistently at each replica and changed via the replication protocol. Allow dynamic changes to server cluster membership -- Key: ZOOKEEPER-107 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-107 Project: Zookeeper Issue Type: Improvement Components: server Reporter: Patrick Hunt Currently cluster membership is statically defined, adding/removing hosts to/from the server cluster dynamically needs to be supported. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-44) DataTree does not use natural sort for getChildren
[ https://issues.apache.org/jira/browse/ZOOKEEPER-44?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12619163#action_12619163 ] Benjamin Reed commented on ZOOKEEPER-44: +1 Fantastic job Jakob! This looks great. Test cases and everything. DataTree does not use natural sort for getChildren -- Key: ZOOKEEPER-44 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-44 Project: Zookeeper Issue Type: Improvement Components: server Affects Versions: 3.0.0 Reporter: Stu Hood Assignee: Jakob Homan Priority: Minor Fix For: 3.0.0 Attachments: seqfile.diff DataTree.getChildren() performs Collection.sort() on the list of children before returning it, but Java's default comparator for Strings will sort 'lock-20' before 'lock-3' for instance. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-44) DataTree does not use natural sort for getChildren
[ https://issues.apache.org/jira/browse/ZOOKEEPER-44?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Reed updated ZOOKEEPER-44: --- Hadoop Flags: [Reviewed] DataTree does not use natural sort for getChildren -- Key: ZOOKEEPER-44 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-44 Project: Zookeeper Issue Type: Improvement Components: server Affects Versions: 3.0.0 Reporter: Stu Hood Assignee: Jakob Homan Priority: Minor Fix For: 3.0.0 Attachments: seqfile.diff DataTree.getChildren() performs Collection.sort() on the list of children before returning it, but Java's default comparator for Strings will sort 'lock-20' before 'lock-3' for instance. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-84) provide a mechanism to reconnect a ZooKeeper if a client receives a SessionExpiredException
[ https://issues.apache.org/jira/browse/ZOOKEEPER-84?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12619604#action_12619604 ] Benjamin Reed commented on ZOOKEEPER-84: I've documented why Facade is a bad idea on the wiki: http://wiki.apache.org/hadoop/ZooKeeper/ErrorHandling provide a mechanism to reconnect a ZooKeeper if a client receives a SessionExpiredException --- Key: ZOOKEEPER-84 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-84 Project: Zookeeper Issue Type: Improvement Components: java client Reporter: james strachan Assignee: james strachan Attachments: reconnect_patch.patch am about to attach a patch which adds a reconnect() method to easily re-establish a connection if a session expires - along with a toString() implementation for easier debugging -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (ZOOKEEPER-49) SetACL does not work
[
https://issues.apache.org/jira/browse/ZOOKEEPER-49?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Reed resolved ZOOKEEPER-49.
Resolution: Fixed
The patch for the dependent issue fixed this issue as well.
SetACL does not work
Key: ZOOKEEPER-49
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-49
Project: Zookeeper
Issue Type: Bug
Components: server
Reporter: Benjamin Reed
Assignee: Benjamin Reed
As reported by Shane:
Still exploring the ACL stuff in Zookeeper. Tried using setACL for a
path but get InvalidACL error thrown looking at pRequest in
PrepRequestProcessor ... and in particular these lines ...
SetACLRequest setAclRequest = new SetACLRequest();
if (!fixupACL(request.authInfo,
setAclRequest.getAcl())) {
throw new KeeperException(Code.InvalidACL);
}
a new SetACLRequest will return a null when called in fixupACL
returning false and throwing the exception as far as I can see.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-91) provide an option for the WriteLock to also watch the locks own znode, so that if someone else deletes it then it is equivalent to calling WriteLock.unlock()
[ https://issues.apache.org/jira/browse/ZOOKEEPER-91?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12619882#action_12619882 ] Benjamin Reed commented on ZOOKEEPER-91: +1 provide an option for the WriteLock to also watch the locks own znode, so that if someone else deletes it then it is equivalent to calling WriteLock.unlock() - Key: ZOOKEEPER-91 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-91 Project: Zookeeper Issue Type: Sub-task Components: java client Reporter: james strachan Most clients probably wont need this, but it could be a handy system management feature to allow the WriteLock to watch its own znode so that if someone else deletes it, it then relinquishes the lock and tries to get it back again -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-103) Reorganize the ZooKeeper source distro to follow maven conventions
[ https://issues.apache.org/jira/browse/ZOOKEEPER-103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12620013#action_12620013 ] Benjamin Reed commented on ZOOKEEPER-103: - I think we need to postpone this issue. It is causing a tremendous amount of distraction when we are right in the middle of getting out the next release. The proposal here conflicts with the proposal for maintaining recipes under contrib. It is also starting to hold up patches since the tree structure is considered in flux while this issue is open. In my opinion now is not the time for a tree restructuring. Lets focus on getting the patch backlog cleaned out and getting the release ready. Reorganize the ZooKeeper source distro to follow maven conventions -- Key: ZOOKEEPER-103 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-103 Project: Zookeeper Issue Type: Improvement Components: build Reporter: Hiram Chirino Assignee: Hiram Chirino Fix For: 3.0.0 Attachments: ZOOKEEPER-103.patch, ZOOKEEPER-103.sh This was sugested as way to bridge the gap in ZOOKEEPER-83 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-113) ZooKeeper.java should be interface not concrete class.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12621497#action_12621497 ] Benjamin Reed commented on ZOOKEEPER-113: - I don't think moving to an interface would help you have a pluggable ClientCnxn class. You still want all the logic for the sync and async code as well as the event threads from the ZooKeeper class. Making ClientCnxn an interface would be a reasonable thing to do once we have another implementation of the ClientCnxn. ZooKeeper.java should be interface not concrete class. -- Key: ZOOKEEPER-113 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-113 Project: Zookeeper Issue Type: Improvement Components: java client Reporter: Patrick Hunt I think ZooKeeper class in src/java/main should be an interface rather than a concrete class. Among other OO goodness this would give us more flexibility when implementing tests on client code. Would also require something like a factory to be created, which might actually work well with another JIRA we have which is the idea to use a URI(s) rather than a host:port combination when creating zookeeper clients. Unfortunately this would have a big impact on clients as it's not b/w compatible (instantiating a new client that is). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-122) NPE in jute's Utils.toCSVString
[ https://issues.apache.org/jira/browse/ZOOKEEPER-122?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Reed updated ZOOKEEPER-122: Hadoop Flags: [Reviewed] NPE in jute's Utils.toCSVString --- Key: ZOOKEEPER-122 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-122 Project: Zookeeper Issue Type: Bug Reporter: Anthony Urso Assignee: Anthony Urso Attachments: ZOOKEEPER-122.patch java.lang.NullPointerException at org.apache.jute.Utils.toCSVString(Utils.java:128) at org.apache.jute.CsvOutputArchive.writeString(CsvOutputArchive.java:94 ) at org.apache.zookeeper.proto.WatcherEvent.toString(WatcherEvent.java:60 ) at java.lang.String.valueOf(String.java:2827) at java.lang.StringBuilder.append(StringBuilder.java:115) at com.liveoffice.mailindex.watchers.SuicidalWatcher.process(SuicidalWat cher.java:11) at org.apache.zookeeper.ZooKeeper.processWatchEvent(ZooKeeper.java:157) at org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:268) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (ZOOKEEPER-131) Old leader election can elect a dead leader over and over again
Old leader election can elect a dead leader over and over again --- Key: ZOOKEEPER-131 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-131 Project: Zookeeper Issue Type: Bug Components: leaderElection Reporter: Benjamin Reed I think there is a race condition that is probably easy to get into with the old leader election and a large number of servers: 1) Leader dies 2) Followers start looking for a new leader before all Followers have abandoned the Leader 3) The Followers looking for a new leader see votes of Followers still following the (now dead) Leader and start voting for the dead Leader 4) The dead Leader gets reelected. For the old leader election a server should not vote for another server that is not nominating himself. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-112) src/java/main ZooKeeper.java has test code embedded into it.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12628352#action_12628352 ] Benjamin Reed commented on ZOOKEEPER-112: - +1 I do have some nits: I don't really like the name ZooKeeperStub, since stub usually refers to a non functional implementation. ZooKeeperStub is fully functional but also allows disconnection. Perhaps DisconnectableZooKeeper maybe? You trade having disconnect on ZooKeeper with making ClientCnxn public, which also pollutes the public API. Perhaps ZooKeeperStub should go into src/java/test/org/apache/zookeeper/ZooKeeperStub. That way you get package visibility for ClientCnxn, but you still keep ZooKeeperStub out of the main tree. Both are just nits, and I support committing the change if you don't want to fix it. src/java/main ZooKeeper.java has test code embedded into it. Key: ZOOKEEPER-112 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-112 Project: Zookeeper Issue Type: Bug Components: tests Reporter: Patrick Hunt Assignee: Patrick Hunt Fix For: 3.0.0 Attachments: ZOOKEEPER-112.patch, ZOOKEEPER-112.patch src/java/main ZooKeeper.java has a method public void disconnect() that is not part of the public api but put there for testing purposes (to test disconnection of the client from the server w/o actually shutting down the session) This method needs to be moved out of the public api. preferably we should have a subclass in the test code itself that provides this method. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-133) hudson tests failing intermittently
[ https://issues.apache.org/jira/browse/ZOOKEEPER-133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12628361#action_12628361 ] Benjamin Reed commented on ZOOKEEPER-133: - I'm thrown by: +// small chance that is hasn't been delivered yet, ignore +assertEquals(0, watchers[i].events.size()); Why would we ignore? If size 0, it means that we got an event we weren't expecting right? The check looks correct, but the comment looks wrong. hudson tests failing intermittently --- Key: ZOOKEEPER-133 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-133 Project: Zookeeper Issue Type: Bug Components: tests Affects Versions: 3.0.0 Reporter: Patrick Hunt Assignee: Patrick Hunt Fix For: 3.0.0 Attachments: ZOOKEEPER-133.patch There is a bug in the ClientTest.java unit test, timing issue in withWatcherObj test. Patch forthcoming. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-134) findbugs cleanup
[ https://issues.apache.org/jira/browse/ZOOKEEPER-134?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12628362#action_12628362 ] Benjamin Reed commented on ZOOKEEPER-134: - +1 ready to commit findbugs cleanup Key: ZOOKEEPER-134 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-134 Project: Zookeeper Issue Type: Improvement Affects Versions: 3.0.0 Reporter: Patrick Hunt Assignee: Patrick Hunt Fix For: 3.0.0 Attachments: ZOOKEEPER-134.patch cleaned up a number of findbugs warnings, in particular: 1) added @overrides appropriately 2) import cleanups 3) log or document many empty blocks 4) resource cleanup (usually by adding finally blocks) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-135) Fat jar build target
[ https://issues.apache.org/jira/browse/ZOOKEEPER-135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Reed updated ZOOKEEPER-135: Attachment: ZOOKEEPER-135.patch This patch modifies the build file to create an optional fat-jar target. This target will only be build if explicitly requested. The fat-jar will have everything in it. The MainClass is a simple redirector that uses a mainClasses file to execute the main() methods of other classes. Fat jar build target Key: ZOOKEEPER-135 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-135 Project: Zookeeper Issue Type: New Feature Components: build Reporter: Benjamin Reed Priority: Minor Attachments: ZOOKEEPER-135.patch For testing and experimentation purposes it would be nice to have everything in a self contained executable jar file that you can plop down on a machine and run. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-134) findbugs cleanup
[ https://issues.apache.org/jira/browse/ZOOKEEPER-134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Reed updated ZOOKEEPER-134: Hadoop Flags: [Reviewed] findbugs cleanup Key: ZOOKEEPER-134 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-134 Project: Zookeeper Issue Type: Improvement Affects Versions: 3.0.0 Reporter: Patrick Hunt Assignee: Patrick Hunt Fix For: 3.0.0 Attachments: ZOOKEEPER-134.patch cleaned up a number of findbugs warnings, in particular: 1) added @overrides appropriately 2) import cleanups 3) log or document many empty blocks 4) resource cleanup (usually by adding finally blocks) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-134) findbugs cleanup
[ https://issues.apache.org/jira/browse/ZOOKEEPER-134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Reed updated ZOOKEEPER-134: Resolution: Fixed Status: Resolved (was: Patch Available) Committed revision 692164. findbugs cleanup Key: ZOOKEEPER-134 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-134 Project: Zookeeper Issue Type: Improvement Affects Versions: 3.0.0 Reporter: Patrick Hunt Assignee: Patrick Hunt Fix For: 3.0.0 Attachments: ZOOKEEPER-134.patch cleaned up a number of findbugs warnings, in particular: 1) added @overrides appropriately 2) import cleanups 3) log or document many empty blocks 4) resource cleanup (usually by adding finally blocks) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-133) hudson tests failing intermittently
[ https://issues.apache.org/jira/browse/ZOOKEEPER-133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Reed updated ZOOKEEPER-133: Resolution: Fixed Status: Resolved (was: Patch Available) Committed revision 692452. hudson tests failing intermittently --- Key: ZOOKEEPER-133 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-133 Project: Zookeeper Issue Type: Bug Components: tests Affects Versions: 3.0.0 Reporter: Patrick Hunt Assignee: Patrick Hunt Fix For: 3.0.0 Attachments: ZOOKEEPER-133.patch, ZOOKEEPER-133.patch There is a bug in the ClientTest.java unit test, timing issue in withWatcherObj test. Patch forthcoming. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-112) src/java/main ZooKeeper.java has test code embedded into it.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Reed updated ZOOKEEPER-112: Resolution: Fixed Hadoop Flags: [Reviewed] Status: Resolved (was: Patch Available) Committed revision 692534. src/java/main ZooKeeper.java has test code embedded into it. Key: ZOOKEEPER-112 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-112 Project: Zookeeper Issue Type: Bug Components: tests Reporter: Patrick Hunt Assignee: Patrick Hunt Fix For: 3.0.0 Attachments: ZOOKEEPER-112.patch, ZOOKEEPER-112.patch, ZOOKEEPER-112.patch src/java/main ZooKeeper.java has a method public void disconnect() that is not part of the public api but put there for testing purposes (to test disconnection of the client from the server w/o actually shutting down the session) This method needs to be moved out of the public api. preferably we should have a subclass in the test code itself that provides this method. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-136) sync causes hang in all followers of quorum
[ https://issues.apache.org/jira/browse/ZOOKEEPER-136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Reed updated ZOOKEEPER-136: Attachment: (was: log_ZOOKEEPER-136.txt) sync causes hang in all followers of quorum --- Key: ZOOKEEPER-136 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-136 Project: Zookeeper Issue Type: Bug Affects Versions: 3.0.0 Reporter: Patrick Hunt Assignee: Benjamin Reed Fix For: 3.0.0 The attached test causes all of the followers of a quorum to hang. Leader continues to function correctly. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-136) sync causes hang in all followers of quorum
[ https://issues.apache.org/jira/browse/ZOOKEEPER-136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Reed updated ZOOKEEPER-136: Attachment: (was: testfails_ZOOKEEPER-136.patch) sync causes hang in all followers of quorum --- Key: ZOOKEEPER-136 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-136 Project: Zookeeper Issue Type: Bug Affects Versions: 3.0.0 Reporter: Patrick Hunt Assignee: Benjamin Reed Fix For: 3.0.0 The attached test causes all of the followers of a quorum to hang. Leader continues to function correctly. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-136) sync causes hang in all followers of quorum
[ https://issues.apache.org/jira/browse/ZOOKEEPER-136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Reed updated ZOOKEEPER-136: Status: Patch Available (was: Open) sync causes hang in all followers of quorum --- Key: ZOOKEEPER-136 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-136 Project: Zookeeper Issue Type: Bug Affects Versions: 3.0.0 Reporter: Patrick Hunt Assignee: Benjamin Reed Fix For: 3.0.0 Attachments: ZOOKEEPER-136.patch The attached test causes all of the followers of a quorum to hang. Leader continues to function correctly. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-136) sync causes hang in all followers of quorum
[ https://issues.apache.org/jira/browse/ZOOKEEPER-136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Reed updated ZOOKEEPER-136: Attachment: ZOOKEEPER-136.patch This patch includes the tests that Pat wrote and the fix for the problem. The fix involves three things: 1) The leader creates a FollowerSyncRequest that contains a reference to the FollowerHandler doing the sync. This allows us to get rid of the handler hashmap. 2) The pendingSyncs uses a List to track multiple syncs per change 3) CommitRequest processor was changed to take a boolean to flag whether to wait for syncs to come from the leader. sync causes hang in all followers of quorum --- Key: ZOOKEEPER-136 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-136 Project: Zookeeper Issue Type: Bug Affects Versions: 3.0.0 Reporter: Patrick Hunt Assignee: Benjamin Reed Fix For: 3.0.0 Attachments: ZOOKEEPER-136.patch The attached test causes all of the followers of a quorum to hang. Leader continues to function correctly. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-136) sync causes hang in all followers of quorum
[ https://issues.apache.org/jira/browse/ZOOKEEPER-136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Reed updated ZOOKEEPER-136: Attachment: ZOOKEEPER-136.patch Added missing SyncTest. sync causes hang in all followers of quorum --- Key: ZOOKEEPER-136 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-136 Project: Zookeeper Issue Type: Bug Affects Versions: 3.0.0 Reporter: Patrick Hunt Assignee: Benjamin Reed Fix For: 3.0.0 Attachments: ZOOKEEPER-136.patch The attached test causes all of the followers of a quorum to hang. Leader continues to function correctly. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-136) sync causes hang in all followers of quorum
[ https://issues.apache.org/jira/browse/ZOOKEEPER-136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Reed updated ZOOKEEPER-136: Status: Patch Available (was: Open) sync causes hang in all followers of quorum --- Key: ZOOKEEPER-136 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-136 Project: Zookeeper Issue Type: Bug Affects Versions: 3.0.0 Reporter: Patrick Hunt Assignee: Benjamin Reed Fix For: 3.0.0 Attachments: ZOOKEEPER-136.patch The attached test causes all of the followers of a quorum to hang. Leader continues to function correctly. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-135) Fat jar build target
[ https://issues.apache.org/jira/browse/ZOOKEEPER-135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Reed updated ZOOKEEPER-135: Attachment: (was: ZOOKEEPER-135.patch) Fat jar build target Key: ZOOKEEPER-135 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-135 Project: Zookeeper Issue Type: New Feature Components: build Reporter: Benjamin Reed Priority: Minor For testing and experimentation purposes it would be nice to have everything in a self contained executable jar file that you can plop down on a machine and run. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-131) Old leader election can elect a dead leader over and over again
[ https://issues.apache.org/jira/browse/ZOOKEEPER-131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Reed updated ZOOKEEPER-131: Status: Patch Available (was: Open) Old leader election can elect a dead leader over and over again --- Key: ZOOKEEPER-131 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-131 Project: Zookeeper Issue Type: Bug Components: leaderElection Reporter: Benjamin Reed Attachments: ZOOKEEPER-131.patch I think there is a race condition that is probably easy to get into with the old leader election and a large number of servers: 1) Leader dies 2) Followers start looking for a new leader before all Followers have abandoned the Leader 3) The Followers looking for a new leader see votes of Followers still following the (now dead) Leader and start voting for the dead Leader 4) The dead Leader gets reelected. For the old leader election a server should not vote for another server that is not nominating himself. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-131) Old leader election can elect a dead leader over and over again
[ https://issues.apache.org/jira/browse/ZOOKEEPER-131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Reed updated ZOOKEEPER-131: Attachment: ZOOKEEPER-131.patch This patch adds a test case that reproduces the problem and a fix (that passes the test). The fix simply removes votes for hosts that a peer has not heard from before the vote is counted. Old leader election can elect a dead leader over and over again --- Key: ZOOKEEPER-131 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-131 Project: Zookeeper Issue Type: Bug Components: leaderElection Reporter: Benjamin Reed Attachments: ZOOKEEPER-131.patch I think there is a race condition that is probably easy to get into with the old leader election and a large number of servers: 1) Leader dies 2) Followers start looking for a new leader before all Followers have abandoned the Leader 3) The Followers looking for a new leader see votes of Followers still following the (now dead) Leader and start voting for the dead Leader 4) The dead Leader gets reelected. For the old leader election a server should not vote for another server that is not nominating himself. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-137) client watcher objects can lose events
[ https://issues.apache.org/jira/browse/ZOOKEEPER-137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Reed updated ZOOKEEPER-137: Hadoop Flags: [Reviewed] +1 Looks good client watcher objects can lose events -- Key: ZOOKEEPER-137 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-137 Project: Zookeeper Issue Type: Bug Components: java client Affects Versions: 3.0.0 Reporter: Patrick Hunt Assignee: Patrick Hunt Fix For: 3.0.0 Attachments: ZOOKEEPER-137.patch if a single watcher (A) is registered on a single node for both a getdata and exists watch the second watch event may be lost: 1) getdata(node, A) 2) setdata(node...) 3) exists(node, A) 4) delete(node...) if watch events for 2 is processed on the client (zookeeper.java, zkwatcher) after 3 completes then the zkwatcher process event method will clear the watch and the subsequent operation's (4) event will be ignored -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-117) threading issues in Leader election
[ https://issues.apache.org/jira/browse/ZOOKEEPER-117?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Reed updated ZOOKEEPER-117: Hadoop Flags: [Reviewed] +1 Looks good threading issues in Leader election --- Key: ZOOKEEPER-117 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-117 Project: Zookeeper Issue Type: Bug Components: server Affects Versions: 3.0.0 Reporter: Patrick Hunt Assignee: Flavio Paiva Junqueira Fix For: 3.0.0 Attachments: ZOOKEEPER-117.patch, ZOOKEEPER-117.patch Leader.lead() creates a new thread that can never terminate (short of restarting vm) naked notifyall in lead() method - what is the condition variable? Best if set inside the sync block -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-38) headers (version+) in log/snap files
[ https://issues.apache.org/jira/browse/ZOOKEEPER-38?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12634267#action_12634267 ] Benjamin Reed commented on ZOOKEEPER-38: This looks great Mahadev. Just small comments: - In ZooKeeperServerMain you changed from using the configuration methods to putting everything in the constructor. I think we should stick with the configuration methods. (This same comment applies to Leader and QuorumPeer - In FileSnapLog.deserialize() if the snapshot is bad, you should try an earlier snapshot. (We should add a test case for this) - SnapLog should really be called Snapshot since it does not have a log component - In FileTxnLog.getLogFiles() you should add a comment to the first (fzxid logZxid) check that you are taking advantage of the fact that the files are sorted, so the last time this condition is true will be for the log file that has snapshotZxid. - In FileTxnLog.getLastLoggedZxid() the comment is a bit unclear. I think this method will also have a problem if the last logfile consists of a single corrupt entry. - In FileTxnLog.truncate() you may need to delete files as well if the zxid you are truncing to is in a log file before the last file - TxnLogCompletion is not used and should be removed - The Util class has some methods that are not used that should be removed. headers (version+) in log/snap files Key: ZOOKEEPER-38 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-38 Project: Zookeeper Issue Type: New Feature Components: server Reporter: Patrick Hunt Assignee: Mahadev konar Fix For: 3.0.0 Attachments: ZOOKEEPER-38.patch, ZOOKEEPER-38.patch, ZOOKEEPER-38.patch, ZOOKEEPER-38_1.patch, ZOOKEEPER-38_2.patch, ZOOKEEPER-38_3.patch, ZOOKEEPER-38_5.patch, ZOOKEEPER-38_6.patch, ZOOKEEPER-38_7.patch Moved from SourceForge to Apache. http://sourceforge.net/tracker/index.php?func=detailaid=1961767group_id=209147atid=1008547 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-117) threading issues in Leader election
[ https://issues.apache.org/jira/browse/ZOOKEEPER-117?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Reed updated ZOOKEEPER-117: Resolution: Fixed Status: Resolved (was: Patch Available) Committed revision 698743. threading issues in Leader election --- Key: ZOOKEEPER-117 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-117 Project: Zookeeper Issue Type: Bug Components: server Affects Versions: 3.0.0 Reporter: Patrick Hunt Assignee: Flavio Paiva Junqueira Fix For: 3.0.0 Attachments: ZOOKEEPER-117.patch, ZOOKEEPER-117.patch Leader.lead() creates a new thread that can never terminate (short of restarting vm) naked notifyall in lead() method - what is the condition variable? Best if set inside the sync block -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-38) headers (version+) in log/snap files
[ https://issues.apache.org/jira/browse/ZOOKEEPER-38?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Reed updated ZOOKEEPER-38: --- Hadoop Flags: [Incompatible change, Reviewed] (was: [Incompatible change]) +1 Looks good mahadev. Marked as an Incompatible change since the data format is not backwards compatible. headers (version+) in log/snap files Key: ZOOKEEPER-38 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-38 Project: Zookeeper Issue Type: New Feature Components: server Reporter: Patrick Hunt Assignee: Mahadev konar Fix For: 3.0.0 Attachments: ZOOKEEPER-38.patch, ZOOKEEPER-38.patch, ZOOKEEPER-38.patch, ZOOKEEPER-38_1.patch, ZOOKEEPER-38_10.patch, ZOOKEEPER-38_11.patch, ZOOKEEPER-38_2.patch, ZOOKEEPER-38_3.patch, ZOOKEEPER-38_5.patch, ZOOKEEPER-38_6.patch, ZOOKEEPER-38_7.patch, ZOOKEEPER-38_8.patch, ZOOKEEPER-38_9.patch Moved from SourceForge to Apache. http://sourceforge.net/tracker/index.php?func=detailaid=1961767group_id=209147atid=1008547 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-38) headers (version+) in log/snap files
[ https://issues.apache.org/jira/browse/ZOOKEEPER-38?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Reed updated ZOOKEEPER-38: --- Resolution: Fixed Hadoop Flags: [Incompatible change, Reviewed] (was: [Reviewed, Incompatible change]) Status: Resolved (was: Patch Available) headers (version+) in log/snap files Key: ZOOKEEPER-38 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-38 Project: Zookeeper Issue Type: New Feature Components: server Reporter: Patrick Hunt Assignee: Mahadev konar Fix For: 3.0.0 Attachments: ZOOKEEPER-38.patch, ZOOKEEPER-38.patch, ZOOKEEPER-38.patch, ZOOKEEPER-38_1.patch, ZOOKEEPER-38_10.patch, ZOOKEEPER-38_11.patch, ZOOKEEPER-38_2.patch, ZOOKEEPER-38_3.patch, ZOOKEEPER-38_5.patch, ZOOKEEPER-38_6.patch, ZOOKEEPER-38_7.patch, ZOOKEEPER-38_8.patch, ZOOKEEPER-38_9.patch Moved from SourceForge to Apache. http://sourceforge.net/tracker/index.php?func=detailaid=1961767group_id=209147atid=1008547 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-127) Use of non-standard election ports in config breaks services
[ https://issues.apache.org/jira/browse/ZOOKEEPER-127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Reed updated ZOOKEEPER-127: Hadoop Flags: [Reviewed] +1 looks good Use of non-standard election ports in config breaks services Key: ZOOKEEPER-127 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-127 Project: Zookeeper Issue Type: Bug Components: quorum Affects Versions: 3.0.0 Reporter: Mark Harwood Assignee: Flavio Paiva Junqueira Priority: Critical Fix For: 3.0.0 Attachments: mhPortChanges.patch, ZOOKEEPER-127.patch, ZOOKEEPER-127.patch, ZOOKEEPER-127.patch, ZOOKEEPER-127.patch, ZOOKEEPER-127.patch, ZOOKEEPER-127.patch In QuorumCnxManager.toSend there is a call to create a connection as follows: channel = SocketChannel.open(new InetSocketAddress(addr, port)); Unfortunately addr is the ip address of a remote server while port is the electionPort of *this* server. As an example, given this configuration (taken from my zoo.cfg) server.1=10.20.9.254:2881 server.2=10.20.9.9:2882 server.3=10.20.9.254:2883 Server 3 was observed trying to make a connection to host 10.20.9.9 on port 2883 and obviously failing. In tests where all machines use the same electionPort this bug would not manifest itself. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-127) Use of non-standard election ports in config breaks services
[ https://issues.apache.org/jira/browse/ZOOKEEPER-127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Reed updated ZOOKEEPER-127: Resolution: Fixed Status: Resolved (was: Patch Available) Committed revision 700714. Use of non-standard election ports in config breaks services Key: ZOOKEEPER-127 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-127 Project: Zookeeper Issue Type: Bug Components: quorum Affects Versions: 3.0.0 Reporter: Mark Harwood Assignee: Flavio Paiva Junqueira Priority: Critical Fix For: 3.0.0 Attachments: mhPortChanges.patch, ZOOKEEPER-127.patch, ZOOKEEPER-127.patch, ZOOKEEPER-127.patch, ZOOKEEPER-127.patch, ZOOKEEPER-127.patch, ZOOKEEPER-127.patch In QuorumCnxManager.toSend there is a call to create a connection as follows: channel = SocketChannel.open(new InetSocketAddress(addr, port)); Unfortunately addr is the ip address of a remote server while port is the electionPort of *this* server. As an example, given this configuration (taken from my zoo.cfg) server.1=10.20.9.254:2881 server.2=10.20.9.9:2882 server.3=10.20.9.254:2883 Server 3 was observed trying to make a connection to host 10.20.9.9 on port 2883 and obviously failing. In tests where all machines use the same electionPort this bug would not manifest itself. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-136) sync causes hang in all followers of quorum
[ https://issues.apache.org/jira/browse/ZOOKEEPER-136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Reed updated ZOOKEEPER-136: Attachment: ZOOKEEPER-136.patch Fixed the comments suggested by Flavio. Updated the patch to trunk. sync causes hang in all followers of quorum --- Key: ZOOKEEPER-136 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-136 Project: Zookeeper Issue Type: Bug Affects Versions: 3.0.0 Reporter: Patrick Hunt Assignee: Benjamin Reed Fix For: 3.0.0 Attachments: ZOOKEEPER-136.patch The attached test causes all of the followers of a quorum to hang. Leader continues to function correctly. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-136) sync causes hang in all followers of quorum
[ https://issues.apache.org/jira/browse/ZOOKEEPER-136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Reed updated ZOOKEEPER-136: Status: Patch Available (was: Open) sync causes hang in all followers of quorum --- Key: ZOOKEEPER-136 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-136 Project: Zookeeper Issue Type: Bug Affects Versions: 3.0.0 Reporter: Patrick Hunt Assignee: Benjamin Reed Fix For: 3.0.0 Attachments: ZOOKEEPER-136.patch The attached test causes all of the followers of a quorum to hang. Leader continues to function correctly. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-154) reliability graph diagram in overview doc needs context
[ https://issues.apache.org/jira/browse/ZOOKEEPER-154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Reed updated ZOOKEEPER-154: Hadoop Flags: [Reviewed] +1 I'm not much of a proof reader, but It looks good to me. You should spell check before you check in. encourged is spelled incorrectly. reliability graph diagram in overview doc needs context --- Key: ZOOKEEPER-154 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-154 Project: Zookeeper Issue Type: Bug Components: documentation Reporter: Patrick Hunt Assignee: Patrick Hunt Priority: Minor Fix For: 3.0.0 Attachments: ZOOKEEPER-154.patch from question on the user mailing list: the Reliability in the Presence of Errors graph on http://hadoop.apache.org/zookeeper/docs/current/zookeeperOver.html does not list how many ZooKeeper quorum nodes are in use, or the fraction of reads/writes. ben mentioned: Here is the missing text: To show the behavior of the system over time as failures are injected we ran a ZooKeeper service made up of 7 machines. We ran the same saturation benchmark as before, but this time we kept the write percentage at a constant 30\%, which is a conservative ratio of our expected workloads. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-156) update programmer guide with acl details from old wiki page
[ https://issues.apache.org/jira/browse/ZOOKEEPER-156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Reed updated ZOOKEEPER-156: Hadoop Flags: [Reviewed] +1 The first sentence of the ACL section refers to ACL but it should be ACLs. I'll leave it to your discretion, but I think the example should be removed since it uses ycl, which is not released. update programmer guide with acl details from old wiki page --- Key: ZOOKEEPER-156 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-156 Project: Zookeeper Issue Type: Task Components: documentation Reporter: Patrick Hunt Assignee: Patrick Hunt Fix For: 3.0.0 Attachments: ZOOKEEPER-156.patch Need to update the programmer guide with the acl details form the old wiki page. http://zookeeper.wiki.sourceforge.net/ZooKeeperACLs -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-157) Peer can't find existing leader
[ https://issues.apache.org/jira/browse/ZOOKEEPER-157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Reed updated ZOOKEEPER-157: Hadoop Flags: [Reviewed] +1 looks good. Peer can't find existing leader --- Key: ZOOKEEPER-157 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-157 Project: Zookeeper Issue Type: Bug Affects Versions: 3.0.0 Reporter: Flavio Paiva Junqueira Assignee: Flavio Paiva Junqueira Priority: Critical Attachments: ZOOKEEPER-157.patch In the patch of JIRA 127, I forgot to set the state of a peer when this peer is looking for a leader and it receives a message from the current leader. In this patch, I have fixed this problem, and also returned to what we had previously. With this current patch, when a peer joins and there is already a leader elected, the joining peer will only recognize the new leader as the leader once it receives a confirmation from a majority. The alternative is to set the leader once we receive a message from a peer claiming to be the leader (what we have on trunk now, although broken because we don't set the state of the peer), but there could be cases in which a peer believes to be leader, although it is not the leader any longer, and the joining peer would select this false leader to be its leader. Eventually, the false leader would timeout, and both processes would select the correct leader. This small fix gets rid of such problems, though. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-159) Cover two corner cases of leader election
[ https://issues.apache.org/jira/browse/ZOOKEEPER-159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Reed updated ZOOKEEPER-159: Hadoop Flags: [Reviewed] +1 Looks good Cover two corner cases of leader election - Key: ZOOKEEPER-159 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-159 Project: Zookeeper Issue Type: Bug Components: leaderElection Reporter: Flavio Paiva Junqueira Assignee: Flavio Paiva Junqueira Fix For: 3.0.0 Attachments: ZOOKEEPER-159.patch In the default implementation of leader election, there are two undesirable cases that need to be covered: 1- If there is a leader elected and this leader is supported by at least quorum of peers, then it can happen that one peer disconnects from the leader, and initiates a new leader election. As it is a new leader election, we increment the logical clock of this peer, and according to the current implementation, this peer won't accept any vote from a peer with a lower LE turn (corresponds to the value of the logical clock of the voting peer). The attached patch corrects this problem by allowing a peer to go back to a previous epoch in the case a majority votes for a leader, and the peer also receives a vote from the leader. This feature allows a peer to correct a false suspicion of the current leader; 2- If a peer advances to a new turn before others, then it may end up voting for a peer that either does not have the highest server id or the the highest zxid. The attached patch fixes this problem by resetting the vote a peer when it updates its logical clock upon receiving a notification with a higher turn value. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-178) FLE test.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Reed updated ZOOKEEPER-178: Hadoop Flags: [Reviewed] +1 Looks good! FLE test. - Key: ZOOKEEPER-178 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-178 Project: Zookeeper Issue Type: Bug Components: leaderElection Reporter: Mahadev konar Assignee: Flavio Paiva Junqueira Fix For: 3.0.0 Attachments: FLE-Fail.txt, TEST-org.apache.zookeeper.test.FLETest.txt, ZOOKEEPER-178.patch fast leader election test failing . -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-33) Better ACL management
[ https://issues.apache.org/jira/browse/ZOOKEEPER-33?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Reed updated ZOOKEEPER-33: --- Status: Open (was: Patch Available) -1 Sorry Mahadev, two small issues (one is super trivial :) 1) convertLongs should be called covertLong since there is only a single Long being converted 2) convertAcls should use a MapListACL, Long to convert an ACL list to a long, otherwise that could become an expensive method when more than a few different ACLs are used. Note, that Map does not need to be serialized and can be deserialized with the MapLong,ListACL Better ACL management - Key: ZOOKEEPER-33 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-33 Project: Zookeeper Issue Type: New Feature Components: server Reporter: Patrick Hunt Assignee: Mahadev konar Fix For: 3.0.0 Attachments: ZOOKEEPER-33.patch, ZOOKEEPER-33.patch, ZOOKEEPER-33.patch, ZOOKEEPER-33.patch, ZOOKEEPER-33.patch, ZOOKEEPER-33.patch Moved from SourceForge to Apache. http://sourceforge.net/tracker/index.php?func=detailaid=1945175group_id=209147atid=1008547 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-33) Better ACL management
[ https://issues.apache.org/jira/browse/ZOOKEEPER-33?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Reed updated ZOOKEEPER-33: --- Hadoop Flags: [Incompatible change, Reviewed] (was: [Incompatible change]) +1 Great job! Thanx Mahadev. Please fix one tiny thing before you commit (you don't need to do another patch): the comment of aclIndex should be the number of acls that we have in the datatree rather than the max number of acls. Right? The latter sounds like an upper bound to the number of acls you can have. (I would have committed the patch, but you didn't submit it :) Better ACL management - Key: ZOOKEEPER-33 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-33 Project: Zookeeper Issue Type: New Feature Components: server Reporter: Patrick Hunt Assignee: Mahadev konar Fix For: 3.0.0 Attachments: ZOOKEEPER-33.patch, ZOOKEEPER-33.patch, ZOOKEEPER-33.patch, ZOOKEEPER-33.patch, ZOOKEEPER-33.patch, ZOOKEEPER-33.patch, ZOOKEEPER-33.patch Moved from SourceForge to Apache. http://sourceforge.net/tracker/index.php?func=detailaid=1945175group_id=209147atid=1008547 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-185) Improved version of FLETest
[ https://issues.apache.org/jira/browse/ZOOKEEPER-185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Reed updated ZOOKEEPER-185: Hadoop Flags: [Reviewed] +1 Looks good. My only suggestion would be to rename deadCount to successCount or something like that. Improved version of FLETest --- Key: ZOOKEEPER-185 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-185 Project: Zookeeper Issue Type: Improvement Components: leaderElection Affects Versions: 3.0.0 Reporter: Flavio Paiva Junqueira Assignee: Flavio Paiva Junqueira Attachments: ZOOKEEPER-185.patch, ZOOKEEPER-185.patch FLETest sometimes fails because we don't run it along with all other parts of ZooKeeper. I'm attaching a patch that modifies the current implementation of FLETest and simulates the expected behavior of other parts of ZooKeeper when running along with them. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-43) Server side of the auto reset watches patch
[ https://issues.apache.org/jira/browse/ZOOKEEPER-43?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Reed updated ZOOKEEPER-43: --- Attachment: ZOOKEEPER-43.patch This has the server side and the Java client implementation. It also has testcases to cover both. Server side of the auto reset watches patch --- Key: ZOOKEEPER-43 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-43 Project: Zookeeper Issue Type: Improvement Components: server Reporter: Patrick Hunt Assignee: Benjamin Reed Fix For: 3.0.0 Attachments: ZOOKEEPER-43.patch Moved from SourceForge to Apache. http://sourceforge.net/tracker/index.php?func=detailaid=1975262group_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] Updated: (ZOOKEEPER-43) Server side of the auto reset watches patch
[ https://issues.apache.org/jira/browse/ZOOKEEPER-43?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Reed updated ZOOKEEPER-43: --- Status: Patch Available (was: Open) Server side of the auto reset watches patch --- Key: ZOOKEEPER-43 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-43 Project: Zookeeper Issue Type: Improvement Components: server Reporter: Patrick Hunt Assignee: Benjamin Reed Fix For: 3.0.0 Attachments: ZOOKEEPER-43.patch Moved from SourceForge to Apache. http://sourceforge.net/tracker/index.php?func=detailaid=1975262group_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] Updated: (ZOOKEEPER-5) Upgrade Feature in Zookeeper server.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-5?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Reed updated ZOOKEEPER-5: -- Status: Open (was: Patch Available) -1 SnapshotUpgradeV1 should be UpgradeSnapshotV1 since it implements SnapshotUpgrade. createThisSnapshot should be renamed since it doesn't create a snapshot. loadOldDataTree maybe? PersistentStat is going to be changing, so convertDataNode will need to be able to take the old version. Finally, you need test cases. Upgrade Feature in Zookeeper server. Key: ZOOKEEPER-5 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-5 Project: Zookeeper Issue Type: New Feature Components: server Reporter: Mahadev konar Assignee: Mahadev konar Fix For: 3.0.0 Attachments: ZOOKEEPER-5.patch, ZOOKEEPER-5.patch, ZOOKEEPER-5.patch We need an upgrade feature in zookeeper where we can upgrade the old databases to a new one. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-43) Server side of the auto reset watches patch
[ https://issues.apache.org/jira/browse/ZOOKEEPER-43?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Reed updated ZOOKEEPER-43: --- Attachment: (was: ZOOKEEPER-43.patch) Server side of the auto reset watches patch --- Key: ZOOKEEPER-43 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-43 Project: Zookeeper Issue Type: Improvement Components: server Reporter: Patrick Hunt Assignee: Benjamin Reed Fix For: 3.0.0 Moved from SourceForge to Apache. http://sourceforge.net/tracker/index.php?func=detailaid=1975262group_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] Updated: (ZOOKEEPER-43) Server side of the auto reset watches patch
[ https://issues.apache.org/jira/browse/ZOOKEEPER-43?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Reed updated ZOOKEEPER-43: --- Status: Patch Available (was: Open) Server side of the auto reset watches patch --- Key: ZOOKEEPER-43 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-43 Project: Zookeeper Issue Type: Improvement Components: server Reporter: Patrick Hunt Assignee: Benjamin Reed Fix For: 3.0.0 Attachments: ZOOKEEPER-43.patch Moved from SourceForge to Apache. http://sourceforge.net/tracker/index.php?func=detailaid=1975262group_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] Updated: (ZOOKEEPER-43) Server side of the auto reset watches patch
[ https://issues.apache.org/jira/browse/ZOOKEEPER-43?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Reed updated ZOOKEEPER-43: --- Attachment: ZOOKEEPER-43.patch Resynced with trunk. Added tests for local watch objects and global watch objects. Server side of the auto reset watches patch --- Key: ZOOKEEPER-43 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-43 Project: Zookeeper Issue Type: Improvement Components: server Reporter: Patrick Hunt Assignee: Benjamin Reed Fix For: 3.0.0 Attachments: ZOOKEEPER-43.patch Moved from SourceForge to Apache. http://sourceforge.net/tracker/index.php?func=detailaid=1975262group_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] Updated: (ZOOKEEPER-23) Auto reset of watches on reconnect
[ https://issues.apache.org/jira/browse/ZOOKEEPER-23?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Reed updated ZOOKEEPER-23: --- Attachment: ZOOKEEPER-23.patch This is the C client for the auto reset of watches. The patch contains the following: 1) A system test that has tests for watches 2) Fixes to the watches so that we accurately trigger the watches that are active when we get the watch event (rather than watches that are active when the watch event is actually dispatched by the completion thread) 3) To handle exists watch properly, I added another exist hashtable for watches of non existent files 4) Code to use SetWatches to re-register watches when reconnecting Auto reset of watches on reconnect -- Key: ZOOKEEPER-23 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-23 Project: Zookeeper Issue Type: New Feature Components: c client, java client Reporter: Patrick Hunt Assignee: Benjamin Reed Fix For: 3.0.0 Attachments: ZOOKEEPER-23.patch Moved from SourceForge to Apache. http://sourceforge.net/tracker/index.php?func=detailaid=1831413group_id=209147atid=1008547 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-23) Auto reset of watches on reconnect
[ https://issues.apache.org/jira/browse/ZOOKEEPER-23?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Reed updated ZOOKEEPER-23: --- Attachment: (was: ZOOKEEPER-23.patch) Auto reset of watches on reconnect -- Key: ZOOKEEPER-23 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-23 Project: Zookeeper Issue Type: New Feature Components: c client, java client Reporter: Patrick Hunt Assignee: Benjamin Reed Fix For: 3.0.0 Moved from SourceForge to Apache. http://sourceforge.net/tracker/index.php?func=detailaid=1831413group_id=209147atid=1008547 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-23) Auto reset of watches on reconnect
[ https://issues.apache.org/jira/browse/ZOOKEEPER-23?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Reed updated ZOOKEEPER-23: --- Attachment: ZOOKEEPER-23.patch In addition to the previous changes I've updated the docs and fixed a TON of bugs. It turns out that the system test revealed some problems in the existing code. The biggest was a deadlock that can happen when a disconnect occurs. I have not yet got the tests running with single threaded mode. I wonder how many people actually use the single threaded library. I'd love to remove it since it is hard to use, test, and maintain. Could we do the release 3.0 with just the multi-threaded library? Auto reset of watches on reconnect -- Key: ZOOKEEPER-23 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-23 Project: Zookeeper Issue Type: New Feature Components: c client, java client Reporter: Patrick Hunt Assignee: Benjamin Reed Fix For: 3.0.0 Attachments: ZOOKEEPER-23.patch Moved from SourceForge to Apache. http://sourceforge.net/tracker/index.php?func=detailaid=1831413group_id=209147atid=1008547 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-23) Auto reset of watches on reconnect
[ https://issues.apache.org/jira/browse/ZOOKEEPER-23?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Reed updated ZOOKEEPER-23: --- Attachment: ZOOKEEPER-23.patch Okay this patch has single threaded support as well. There are two tests in TestOperations unit test that fail quite often in both single threaded and multi threaded mode, but that class is very opaque and I can't tell if it is a bug in the unit test or if it is exposing a bug. Auto reset of watches on reconnect -- Key: ZOOKEEPER-23 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-23 Project: Zookeeper Issue Type: New Feature Components: c client, java client Reporter: Patrick Hunt Assignee: Benjamin Reed Fix For: 3.0.0 Attachments: ZOOKEEPER-23.patch Moved from SourceForge to Apache. http://sourceforge.net/tracker/index.php?func=detailaid=1831413group_id=209147atid=1008547 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-43) Server side of the auto reset watches patch
[ https://issues.apache.org/jira/browse/ZOOKEEPER-43?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Reed updated ZOOKEEPER-43: --- Hadoop Flags: [Incompatible change] Status: Patch Available (was: Open) Server side of the auto reset watches patch --- Key: ZOOKEEPER-43 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-43 Project: Zookeeper Issue Type: Improvement Components: server Reporter: Patrick Hunt Assignee: Benjamin Reed Fix For: 3.0.0 Attachments: ZOOKEEPER-43.patch, ZOOKEEPER-43.patch, ZOOKEEPER-43.patch, ZOOKEEPER-43.patch, ZOOKEEPER-43.patch, ZOOKEEPER-43.patch Moved from SourceForge to Apache. http://sourceforge.net/tracker/index.php?func=detailaid=1975262group_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-201) validate magic number when reading snapshot and transaction logs
[ https://issues.apache.org/jira/browse/ZOOKEEPER-201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12641472#action_12641472 ] Benjamin Reed commented on ZOOKEEPER-201: - +1 commit validate magic number when reading snapshot and transaction logs Key: ZOOKEEPER-201 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-201 Project: Zookeeper Issue Type: Bug Components: server Affects Versions: 3.0.0 Reporter: Patrick Hunt Assignee: Mahadev konar Priority: Blocker Fix For: 3.0.0 Attachments: ZOOKEEPER-201.patch The snapshot and transaction log files are not validating the magic numbers when read. Mahadev, can you update the code and tests for this? Possible for 3.0 or wait post 3.0? (feel free to fix now or reassign version) Please add tests for this. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-23) Auto reset of watches on reconnect
[ https://issues.apache.org/jira/browse/ZOOKEEPER-23?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Reed updated ZOOKEEPER-23: --- Attachment: (was: ZOOKEEPER-23.patch) Auto reset of watches on reconnect -- Key: ZOOKEEPER-23 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-23 Project: Zookeeper Issue Type: New Feature Components: c client, java client Reporter: Patrick Hunt Assignee: Benjamin Reed Fix For: 3.0.0 Moved from SourceForge to Apache. http://sourceforge.net/tracker/index.php?func=detailaid=1831413group_id=209147atid=1008547 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-23) Auto reset of watches on reconnect
[ https://issues.apache.org/jira/browse/ZOOKEEPER-23?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Reed updated ZOOKEEPER-23: --- Attachment: ZOOKEEPER-23.patch Added LICENSE to zkServer.sh Removed some unit tests that are not implemented correctly Fixed the way we propogate the error in free_completions Auto reset of watches on reconnect -- Key: ZOOKEEPER-23 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-23 Project: Zookeeper Issue Type: New Feature Components: c client, java client Reporter: Patrick Hunt Assignee: Benjamin Reed Fix For: 3.0.0 Attachments: ZOOKEEPER-23.patch Moved from SourceForge to Apache. http://sourceforge.net/tracker/index.php?func=detailaid=1831413group_id=209147atid=1008547 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (ZOOKEEPER-204) SetWatches needs to be the first message after auth messages to the server
SetWatches needs to be the first message after auth messages to the server -- Key: ZOOKEEPER-204 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-204 Project: Zookeeper Issue Type: Bug Components: java client Affects Versions: 3.0.0 Reporter: Benjamin Reed Fix For: 3.0.0 When the ZooKeeper java client makes a connection it queues a SetWatches request. The problem is that it puts the request at the end of the outgoing requests. This means that watches for requests that were queued before the connection is made and after the disconnect may improperly get their watches triggered. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-204) SetWatches needs to be the first message after auth messages to the server
[ https://issues.apache.org/jira/browse/ZOOKEEPER-204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Reed updated ZOOKEEPER-204: Attachment: ZOOKEEPER-204.patch This patch has a test case for the condition. It also fixes the problem by queuing the SetWatches right after the auth packets and before any other packets. While fixing the problem I also fixed the problem of exceptions that happen in callbacks killing the dispatch thread. SetWatches needs to be the first message after auth messages to the server -- Key: ZOOKEEPER-204 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-204 Project: Zookeeper Issue Type: Bug Components: java client Affects Versions: 3.0.0 Reporter: Benjamin Reed Fix For: 3.0.0 Attachments: ZOOKEEPER-204.patch When the ZooKeeper java client makes a connection it queues a SetWatches request. The problem is that it puts the request at the end of the outgoing requests. This means that watches for requests that were queued before the connection is made and after the disconnect may improperly get their watches triggered. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-204) SetWatches needs to be the first message after auth messages to the server
[ https://issues.apache.org/jira/browse/ZOOKEEPER-204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Reed updated ZOOKEEPER-204: Affects Version/s: (was: 3.0.0) 3.1.0 Status: Patch Available (was: Open) SetWatches needs to be the first message after auth messages to the server -- Key: ZOOKEEPER-204 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-204 Project: Zookeeper Issue Type: Bug Components: java client Affects Versions: 3.1.0 Reporter: Benjamin Reed Fix For: 3.0.0 Attachments: ZOOKEEPER-204.patch When the ZooKeeper java client makes a connection it queues a SetWatches request. The problem is that it puts the request at the end of the outgoing requests. This means that watches for requests that were queued before the connection is made and after the disconnect may improperly get their watches triggered. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-204) SetWatches needs to be the first message after auth messages to the server
[ https://issues.apache.org/jira/browse/ZOOKEEPER-204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Reed updated ZOOKEEPER-204: Assignee: (was: Benjamin Reed) SetWatches needs to be the first message after auth messages to the server -- Key: ZOOKEEPER-204 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-204 Project: Zookeeper Issue Type: Bug Components: java client Affects Versions: 3.0.0 Reporter: Benjamin Reed Fix For: 3.1.0 Attachments: ZOOKEEPER-204.patch When the ZooKeeper java client makes a connection it queues a SetWatches request. The problem is that it puts the request at the end of the outgoing requests. This means that watches for requests that were queued before the connection is made and after the disconnect may improperly get their watches triggered. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-202) Phantom ephemeral node
[ https://issues.apache.org/jira/browse/ZOOKEEPER-202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12641908#action_12641908 ] Benjamin Reed commented on ZOOKEEPER-202: - I think it's 2.1.0 from sourceforge. That release was done on 4/29/2008. (It might have been built earlier.) The latest sourceforge release 2.2.1 has the fix. Phantom ephemeral node -- Key: ZOOKEEPER-202 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-202 Project: Zookeeper Issue Type: Bug Reporter: Flavio Paiva Junqueira One of our users has observed that an ephemeral znode had gone away once its creator had disconnected according to the leader, but one follower believed that it existed long after the znode had been deleted. Apparently the follower was never going to delete it. Because the leader wouldn't recognize the znode as an existing one, any attempt to delete the znode failed. We have to investigate if this is related to any known bug, although, to my knowledge, this is the first time it happens. It is important to note that the user was running an older version of our code. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-149) c interface is missing tests against java server (mock only)
[ https://issues.apache.org/jira/browse/ZOOKEEPER-149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12641910#action_12641910 ] Benjamin Reed commented on ZOOKEEPER-149: - The system test only tests the watcher code. We should leave this issue open until we get a more complete suite of system tests. c interface is missing tests against java server (mock only) Key: ZOOKEEPER-149 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-149 Project: Zookeeper Issue Type: Improvement Components: c client Reporter: Patrick Hunt Assignee: Patrick Hunt Fix For: 3.1.0 The c client interface has unit tests but they are against mock server implementations only. We need to add tests for the c interface against live java 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-212) snapshot is synchronous in 3.0
[ https://issues.apache.org/jira/browse/ZOOKEEPER-212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Reed updated ZOOKEEPER-212: Priority: Critical (was: Major) Hadoop Flags: [Reviewed] +1 I can't believe we missed this! I think we should do a 3.0.1 release to get this out soon. This will cause big problems with big databases! snapshot is synchronous in 3.0 -- Key: ZOOKEEPER-212 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-212 Project: Zookeeper Issue Type: Bug Affects Versions: 3.0.0 Reporter: Mahadev konar Assignee: Mahadev konar Priority: Critical Fix For: 3.1.0 Attachments: ZOOKEEPER-212.patch the snapshot in 3.0 is syunchronous. this will affect performance of the system. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-204) SetWatches needs to be the first message after auth messages to the server
[ https://issues.apache.org/jira/browse/ZOOKEEPER-204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Reed updated ZOOKEEPER-204: Attachment: ZOOKEEPER-204.patch Sorry Mahadev, added missing file. SetWatches needs to be the first message after auth messages to the server -- Key: ZOOKEEPER-204 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-204 Project: Zookeeper Issue Type: Bug Components: java client Affects Versions: 3.0.0 Reporter: Benjamin Reed Assignee: Benjamin Reed Fix For: 3.1.0 Attachments: ZOOKEEPER-204.patch, ZOOKEEPER-204.patch When the ZooKeeper java client makes a connection it queues a SetWatches request. The problem is that it puts the request at the end of the outgoing requests. This means that watches for requests that were queued before the connection is made and after the disconnect may improperly get their watches triggered. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-212) snapshot is synchronous in 3.0
[ https://issues.apache.org/jira/browse/ZOOKEEPER-212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Reed updated ZOOKEEPER-212: Attachment: ZOOKEEPER-212-test.patch This test checks for the problem that reported by this issue. I checked that the test fails before Mahadev's patch and passes after. snapshot is synchronous in 3.0 -- Key: ZOOKEEPER-212 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-212 Project: Zookeeper Issue Type: Bug Affects Versions: 3.0.0 Reporter: Mahadev konar Assignee: Mahadev konar Priority: Critical Fix For: 3.1.0 Attachments: ZOOKEEPER-212-test.patch, ZOOKEEPER-212.patch the snapshot in 3.0 is syunchronous. this will affect performance of the system. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-209) nullpointerexception if election port is not specified.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Reed updated ZOOKEEPER-209: Hadoop Flags: [Reviewed] +1 Looks good Flavio nullpointerexception if election port is not specified. --- Key: ZOOKEEPER-209 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-209 Project: Zookeeper Issue Type: Bug Affects Versions: 3.0.1 Reporter: Mahadev konar Assignee: Flavio Paiva Junqueira Fix For: 3.0.0 Attachments: ZOOKEEPER-209.patch The quoruom servers throw a nullpointer exception and still keep running. We should atleast have a nice debug message and quit... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-206) documentation tab should contain the version number (and other small site changes)
[ https://issues.apache.org/jira/browse/ZOOKEEPER-206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12648804#action_12648804 ] Benjamin Reed commented on ZOOKEEPER-206: - +1 documentation tab should contain the version number (and other small site changes) --- Key: ZOOKEEPER-206 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-206 Project: Zookeeper Issue Type: Bug Components: documentation Affects Versions: 3.0.0 Reporter: Patrick Hunt Assignee: Patrick Hunt Priority: Minor Fix For: 3.0.1, 3.1.0 Attachments: ZOOKEEPER-206_301.patch, ZOOKEEPER-206_trunk.patch Feedback from Doug Cutting on 3.0.0 documentation: - The Zookeeper Documentation tab should contain the version number. - Informal Documentation might better be named Other Documentation. - The Other Info page should be removed, since it contains nothing. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-226) exists calls fails on server if node has null data
[ https://issues.apache.org/jira/browse/ZOOKEEPER-226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Reed updated ZOOKEEPER-226: Hadoop Flags: [Reviewed] +1 Ready to commit exists calls fails on server if node has null data -- Key: ZOOKEEPER-226 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-226 Project: Zookeeper Issue Type: Bug Components: server Affects Versions: 3.0.0 Reporter: Patrick Hunt Assignee: Mahadev konar Priority: Blocker Fix For: 3.0.1, 3.1.0 Attachments: ZOOKEEPER-226.patch An NPE will be generated on the server (and resulting in client getting MarshallingException) if exists() is called on a node with null data. workaround is to create the node with non-null data. be sure to update the tests for this case -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-208) Zookeeper C client uses API that are not thread safe, causing crashes when multiple instances are active
[ https://issues.apache.org/jira/browse/ZOOKEEPER-208?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Reed updated ZOOKEEPER-208: Hadoop Flags: [Reviewed] +1 great work. We should include this in 3.0.1 Zookeeper C client uses API that are not thread safe, causing crashes when multiple instances are active Key: ZOOKEEPER-208 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-208 Project: Zookeeper Issue Type: Bug Components: c client Affects Versions: 3.0.0 Environment: Linux Reporter: Austin Shoemaker Assignee: Austin Shoemaker Priority: Critical Fix For: 3.0.1, 3.1.0 Attachments: zookeeper-strtok_getaddrinfo-trunk.patch, zookeeper-strtok_getaddrinfo-trunk.patch The Zookeeper C client library uses gethostbyname and strtok, both of which are not safe to use from multiple threads. The problem is resolved by using getaddrinfo and strtok_r in place of the older API. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-204) SetWatches needs to be the first message after auth messages to the server
[ https://issues.apache.org/jira/browse/ZOOKEEPER-204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Reed updated ZOOKEEPER-204: Attachment: ZOOKEEPER-204.patch Good catch Flavio. Uploaded a fixed version. SetWatches needs to be the first message after auth messages to the server -- Key: ZOOKEEPER-204 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-204 Project: Zookeeper Issue Type: Bug Components: java client Affects Versions: 3.0.0 Reporter: Benjamin Reed Assignee: Benjamin Reed Fix For: 3.0.1, 3.1.0 Attachments: ZOOKEEPER-204.patch, ZOOKEEPER-204.patch, ZOOKEEPER-204.patch When the ZooKeeper java client makes a connection it queues a SetWatches request. The problem is that it puts the request at the end of the outgoing requests. This means that watches for requests that were queued before the connection is made and after the disconnect may improperly get their watches triggered. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-208) Zookeeper C client uses API that are not thread safe, causing crashes when multiple instances are active
[ https://issues.apache.org/jira/browse/ZOOKEEPER-208?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Reed updated ZOOKEEPER-208: Status: Patch Available (was: Open) Zookeeper C client uses API that are not thread safe, causing crashes when multiple instances are active Key: ZOOKEEPER-208 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-208 Project: Zookeeper Issue Type: Bug Components: c client Affects Versions: 3.0.0 Environment: Linux Reporter: Austin Shoemaker Assignee: Austin Shoemaker Priority: Critical Fix For: 3.0.1, 3.1.0 Attachments: ZOOKEEPER-208.patch, zookeeper-strtok_getaddrinfo-trunk.patch, zookeeper-strtok_getaddrinfo-trunk.patch The Zookeeper C client library uses gethostbyname and strtok, both of which are not safe to use from multiple threads. The problem is resolved by using getaddrinfo and strtok_r in place of the older API. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-208) Zookeeper C client uses API that are not thread safe, causing crashes when multiple instances are active
[ https://issues.apache.org/jira/browse/ZOOKEEPER-208?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Reed updated ZOOKEEPER-208: Attachment: ZOOKEEPER-208.patch Updated the tests to not look for usage of gethostbyname. Zookeeper C client uses API that are not thread safe, causing crashes when multiple instances are active Key: ZOOKEEPER-208 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-208 Project: Zookeeper Issue Type: Bug Components: c client Affects Versions: 3.0.0 Environment: Linux Reporter: Austin Shoemaker Assignee: Austin Shoemaker Priority: Critical Fix For: 3.0.1, 3.1.0 Attachments: ZOOKEEPER-208.patch, zookeeper-strtok_getaddrinfo-trunk.patch, zookeeper-strtok_getaddrinfo-trunk.patch The Zookeeper C client library uses gethostbyname and strtok, both of which are not safe to use from multiple threads. The problem is resolved by using getaddrinfo and strtok_r in place of the older API. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-235) SSL Support for clients
[ https://issues.apache.org/jira/browse/ZOOKEEPER-235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Reed updated ZOOKEEPER-235: Priority: Minor (was: Major) SSL Support for clients --- Key: ZOOKEEPER-235 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-235 Project: Zookeeper Issue Type: New Feature Reporter: Benjamin Reed Priority: Minor ZooKeeper should be able to support SSL for ZooKeeper clients. As part of the implementation we should also add an X509AuthenticationProvider so that client side certifications can be used for authentication. The tricky part of the implementation will be integrating with the non-blocking NIO calls that we use. There are various web pages that describe how to do it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (ZOOKEEPER-235) SSL Support for clients
SSL Support for clients --- Key: ZOOKEEPER-235 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-235 Project: Zookeeper Issue Type: New Feature Reporter: Benjamin Reed ZooKeeper should be able to support SSL for ZooKeeper clients. As part of the implementation we should also add an X509AuthenticationProvider so that client side certifications can be used for authentication. The tricky part of the implementation will be integrating with the non-blocking NIO calls that we use. There are various web pages that describe how to do it. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (ZOOKEEPER-236) SSL Support for Atomic Broadcast protocol
SSL Support for Atomic Broadcast protocol - Key: ZOOKEEPER-236 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-236 Project: Zookeeper Issue Type: New Feature Reporter: Benjamin Reed Priority: Minor We should have the ability to use SSL to authenticate and encrypt the traffic between ZooKeeper servers. For the most part this is a very easy change. We would probably only want to support this for TCP based leader elections. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (ZOOKEEPER-237) Add a Chroot request
Add a Chroot request Key: ZOOKEEPER-237 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-237 Project: Zookeeper Issue Type: New Feature Reporter: Benjamin Reed Priority: Minor It would be nice to be able to root ZooKeeper handles at specific points in the namespace, so that applications that use ZooKeeper can work in their own rooted subtree. For example, if ops decides that application X can use the subtree /apps/X and application Y can use the subtree /apps/Y, X can to a chroot to /apps/X and then all its path references can be rooted at /apps/X. Thus when X creates the path /myid, it will actually be creating the path /apps/X/myid. There are two ways we can expose this mechanism: 1) We can simply add a chroot(String path) API, or 2) we can integrate into a service identifier scheme for example zk://server1:2181,server2:2181/my/root. I like the second form personally. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (ZOOKEEPER-238) HostAuthenicationProvider should be removed
HostAuthenicationProvider should be removed --- Key: ZOOKEEPER-238 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-238 Project: Zookeeper Issue Type: Bug Reporter: Benjamin Reed I think the way the HostAuthenticationProvider is implemented could cause serious performance problems if DNS is slow or broken. The problem is that we need to do a reverse hostname resolution during connection establishment. I suggest it be removed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-28) Incompatible client and server list detection
[ https://issues.apache.org/jira/browse/ZOOKEEPER-28?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12650340#action_12650340 ] Benjamin Reed commented on ZOOKEEPER-28: I have been thinking about this more and I've realized that perhaps the easiest/best way to implement this would be to add a ListServers request to the clients. That way clients can do the validation themselves, and it can be done in a backwards compatible fashion. Incompatible client and server list detection - Key: ZOOKEEPER-28 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-28 Project: Zookeeper Issue Type: New Feature Components: c client, java client, server Reporter: Patrick Hunt Moved from SourceForge to Apache. http://sourceforge.net/tracker/index.php?func=detailaid=1937084group_id=209147atid=1008547 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (ZOOKEEPER-239) ZooKeeper System Tests
ZooKeeper System Tests -- Key: ZOOKEEPER-239 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-239 Project: Zookeeper Issue Type: Test Components: c client, java client Reporter: Benjamin Reed It would be nice to have real system tests. Our current Java system tests start everything in the same JVM. It would be nice to be able to start up the servers on different machines. The C tests have a system test with a script to start and stop the cluster. It would be good to extend the script and to make it used by the Java tests as well. If we can standardize on the script, we can have script options for different cluster shells from simple ssh to torque. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-237) Add a Chroot request
[ https://issues.apache.org/jira/browse/ZOOKEEPER-237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12650369#action_12650369 ] Benjamin Reed commented on ZOOKEEPER-237: - If you bind a credential to a root, you end up tying yourself to a particular authorization scheme and id. If ACLs are used, you would not be able to circumvent the root. And by using an identifier not tied to a credential, you can support multiple credentials for a given root. For example, you may have /mySpace1, and you have some clients that are in a trusted cluster that authenticate with ip addresses and others that use stronger credentials. You may also have the converse problem where a given credential may have access to /mySpace1 and /yourSpace2, so the root would be ambiguous. Add a Chroot request Key: ZOOKEEPER-237 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-237 Project: Zookeeper Issue Type: New Feature Reporter: Benjamin Reed Priority: Minor It would be nice to be able to root ZooKeeper handles at specific points in the namespace, so that applications that use ZooKeeper can work in their own rooted subtree. For example, if ops decides that application X can use the subtree /apps/X and application Y can use the subtree /apps/Y, X can to a chroot to /apps/X and then all its path references can be rooted at /apps/X. Thus when X creates the path /myid, it will actually be creating the path /apps/X/myid. There are two ways we can expose this mechanism: 1) We can simply add a chroot(String path) API, or 2) we can integrate into a service identifier scheme for example zk://server1:2181,server2:2181/my/root. I like the second form personally. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-69) ZooKeeper logo
[ https://issues.apache.org/jira/browse/ZOOKEEPER-69?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Reed updated ZOOKEEPER-69: --- Attachment: zk_logo_use.png ZooKeeper logo -- Key: ZOOKEEPER-69 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-69 Project: Zookeeper Issue Type: Wish Components: documentation Reporter: Flavio Paiva Junqueira Assignee: Benjamin Reed Priority: Minor Fix For: 3.1.0 Attachments: pbzk.gif, zk_logo_use.png, zk_logo_use2.png I think we need a cool logo for the project. The ones I've seen so far are a little lame, and that includes the one I've created for SourceForge. If anyone on this list has an idea or knows of anyone with some art skills, plese add a commento to this Jira. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
