[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] 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 ] Patrick Hunt updated ZOOKEEPER-63: -- Status: Open (was: Patch Available) -1 on the patch, still have the stated unresolved issues with this change: 1) there is still the stated race condition 2) what is causing the underlying hang? this should not be happening and needs to be addressed directly, may even be related to item 1 3) if the timeout is reached a warning should be issued in the log I suspect we should split this patch out to it's own jira and make it blocked by this, perhaps that would make it more clear. 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] Assigned: (ZOOKEEPER-108) sync implementation reorders operations
[ https://issues.apache.org/jira/browse/ZOOKEEPER-108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mahadev konar reassigned ZOOKEEPER-108: --- Assignee: Flavio Paiva Junqueira sync implementation reorders operations --- Key: ZOOKEEPER-108 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-108 Project: Zookeeper Issue Type: Bug Components: server Reporter: Flavio Paiva Junqueira Assignee: Flavio Paiva Junqueira Attachments: ZOOKEEPER-108.patch The current implementation of sync is broken. There is a race condition that causes a follower to return operations out of order, causing clients to drop their connections to a server. I'll be attaching a patch to fix this problem shortly. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[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=12619070#action_12619070 ] Patrick Hunt commented on ZOOKEEPER-107: Obviously it would be great if we supported reading from a ZooKeeper cluster! This just reminded me of another comment I got recently on this. The suggestion was to use a URI (similar to jdbc for example) rather than a host/port list. Perhaps we should have some sort of plugin architecture here, where the uri would be provided and each registered plugin would map the host/port mapping based on the scheme. 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-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:all-tabpanel ] Mahadev konar updated ZOOKEEPER-104: Attachment: ZOOKEEPER-104.patch this is the latest patch which throws Runtimeexcpetions with interrupted exceptions and gets rid of the while true loops. 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, ZOOKEEPER-104.patch Here is an implementation of a ZooKeeper backed Java Set. It should be generally useful. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-104) KeptSet: a distributed data stucture backed by the children of a ZooKeeper node
[ https://issues.apache.org/jira/browse/ZOOKEEPER-104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12619076#action_12619076 ] Mahadev konar commented on ZOOKEEPER-104: - once ZOOKEEPER-103 is resolved then we can add the build file to build this contrib module. 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, 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=12619106#action_12619106
]
Hiram Chirino commented on ZOOKEEPER-107:
-
I personally think that this needs to stay decoupled so that group membership
can be controlled via different implementations. In other words, I think that
the QuorumPeer should not have to have any constructor args for it to know it's
peers. It should persistently store/remember what the list of peers are part
of the group since it last started.
Not sure if it makes sense to keep that list in the ZK db or not.
When a node that is not part of a cluster first starts up, it needs to know if
it's starting a new cluster or if it is joining an existing cluster.
Therefore, I think the QuorumPeer class needs methods like the following:
{code}
/**
* Contacts a ZK server in the cluster, adds this peer to the cluster and gets
a listing of the rest of the peers in
* the cluster.
*
* Optional: is slaveOnly is true, then this peer should never be elected
master.
*
* Throws an error if this peer is already part of a cluster.
*/
void joinCluster( URI server, bool slaveOnly )
/**
* Starts this peer as the first node in the cluster and makes him the master.
*
* Throws an error if this peer is already part of a cluster.
*/
void createCluster()
/**
* Removes this peer from the peer list maintained by the cluster.
*
* Throws an error if this peer is not part of a cluster.
*/
void leaveCluster()
/**
* Gets a list of peers in the cluser.
*
* @return null if not part of a cluster yet.
*/
ListURI getClusterPeers()
{code}
If methods like the above are available, then an administrator can dynamically
manage adding/removing nodes on an existing ZooKeeper cluster. or some
automated agent could do it. Note that the peer list needs to get replicated
to all cluster members and persisted to avoid split brain issues on peer
restart. Operations like joinCluster(), leaveCluster(), getClusterPeers()
would block until a master is elected in the cluster.
Please note the 'nice to have feature' where you have the ability to designate
some peers as NOT being eligible to become a master. This would allow you to
support using heterogeneous peers, and enforce only allowing the higher end
machines to become the masters.
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-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=12619107#action_12619107 ] Hiram Chirino commented on ZOOKEEPER-103: - The maven convention is to have each module/jar the it's own directory who's name matches the module/jar name. The ant build does not do this (yet) but in the maven build, you end up with zookeeper-xxx.jar files. 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-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-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=12619111#action_12619111 ] Doug Cutting commented on ZOOKEEPER-103: The maven convention is to have each module/jar the it's own directory who's name matches the module/jar name. That imposes big, redundant directory names. Is there no way to configure Maven otherwise? 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-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=12619118#action_12619118 ] Mahadev konar commented on ZOOKEEPER-107: - +1 for using URI's on the client side to get a list of zookeeper servers . We can always update the zookeeper client periodically by fetching from the URI 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-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=12619119#action_12619119 ] Patrick Hunt commented on ZOOKEEPER-107: In my comment URI rather than a host/port list I was specifically referring to the client's host/port list used to specify the servers to which the client should connect. Probably a good idea to use something like this on the servers as well. Regarding the idea of join/leave a cluster, this sounds good. How does this mesh with the common case of starting up a set of 5 servers forming a new cluster? Specifically the idea of operations blocking (hiram's comment) until master is elected. Not sure I see how this works... 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.
Re: ZooKeeper test harness needs work
Could be, but I don't think I'm seeing that in the test failure cases I've seen lately. In some cases the VM itself was crashing! Notice ZOOKEEPER-2 was seeing NPEs in the QuorumPeer. I did notice in AsyncTest that it's closing the server(s) before closing the clients, which is causing alot of noise in the logs (planning to patch that). What OS/cpu type configuration are you on? I'm on Ubuntu on 1core cpu. Patrick Hiram Chirino wrote: Lots of times when a test runs it seems like the ports are already bound. Anybody else see this? Is this the cause of the intermittent failures you see? Regards, Hiram On Wed, Jul 30, 2008 at 12:32 PM, Patrick Hunt [EMAIL PROTECTED] wrote: I'm soliciting ideas on how to improve the reliability and usability (creating new tests in particular) of our current test harness. Hudson and some users are seeing intermittent failures, primarily due to timing related issue in test setup; the test starts a server, runs some tests, then shuts down the server, loop to the next test. There is some code in ClientBase that's supposed to provide a latch for the server startup, but we also have a number of sleeps in the test setup, without which the tests fail more frequently (so something is still busted). In particular I want to make it easier to write server tests and to remove the need for sleeps as this causes the unit tests to run slowly. Additionally we are seeing a need to tests clients in addition to the server (much of our current testing is related to verifying the correct function of the zk server). In this case we are not currently able to test any client failure handling cases (such as disconnect handling) as we are running against a fully functional zk server. I'm thinking we should do two things: 1) create a better test harness for the server 2) implement a mock ZooKeeper.java that has similar semantics as zk server proper but has the capability to inject/reproduce/verify various error scenarios for client testing. If you have any ideas/suggestions/comments/etc.. or would like to work on/with please let me know. Patrick
Re: ZooKeeper test harness needs work
I was dual core Intel Mac Book Pro. On Fri, Aug 1, 2008 at 4:57 PM, Patrick Hunt [EMAIL PROTECTED] wrote: Could be, but I don't think I'm seeing that in the test failure cases I've seen lately. In some cases the VM itself was crashing! Notice ZOOKEEPER-2 was seeing NPEs in the QuorumPeer. I did notice in AsyncTest that it's closing the server(s) before closing the clients, which is causing alot of noise in the logs (planning to patch that). What OS/cpu type configuration are you on? I'm on Ubuntu on 1core cpu. Patrick Hiram Chirino wrote: Lots of times when a test runs it seems like the ports are already bound. Anybody else see this? Is this the cause of the intermittent failures you see? Regards, Hiram On Wed, Jul 30, 2008 at 12:32 PM, Patrick Hunt [EMAIL PROTECTED] wrote: I'm soliciting ideas on how to improve the reliability and usability (creating new tests in particular) of our current test harness. Hudson and some users are seeing intermittent failures, primarily due to timing related issue in test setup; the test starts a server, runs some tests, then shuts down the server, loop to the next test. There is some code in ClientBase that's supposed to provide a latch for the server startup, but we also have a number of sleeps in the test setup, without which the tests fail more frequently (so something is still busted). In particular I want to make it easier to write server tests and to remove the need for sleeps as this causes the unit tests to run slowly. Additionally we are seeing a need to tests clients in addition to the server (much of our current testing is related to verifying the correct function of the zk server). In this case we are not currently able to test any client failure handling cases (such as disconnect handling) as we are running against a fully functional zk server. I'm thinking we should do two things: 1) create a better test harness for the server 2) implement a mock ZooKeeper.java that has similar semantics as zk server proper but has the capability to inject/reproduce/verify various error scenarios for client testing. If you have any ideas/suggestions/comments/etc.. or would like to work on/with please let me know. Patrick -- Regards, Hiram Blog: http://hiramchirino.com Open Source SOA http://open.iona.com
[jira] Updated: (ZOOKEEPER-109) cleanup of NPE and Resource issue nits found by static analysis
[ https://issues.apache.org/jira/browse/ZOOKEEPER-109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Hunt updated ZOOKEEPER-109: --- Status: Patch Available (was: Open) Cleaned up some issues found during static code analysis, specifically some potential NPE and resource leaks (close socket/stream). cleanup of NPE and Resource issue nits found by static analysis --- Key: ZOOKEEPER-109 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-109 Project: Zookeeper Issue Type: Bug Components: server Affects Versions: 3.0.0 Reporter: Patrick Hunt Assignee: Patrick Hunt Attachments: ZOOKEEPER-109.patch NPE/ResourceLeak cleanup for issues found during static analysis. -- 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 ] Jakob Homan updated ZOOKEEPER-44: - Attachment: seqfile.diff Implements the changes discussed in the Jira. 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: Benjamin Reed 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] Assigned: (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 ] Mahadev konar reassigned ZOOKEEPER-44: -- Assignee: Jakob Homan (was: Benjamin Reed) 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-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-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=12619164#action_12619164 ] Mahadev konar commented on ZOOKEEPER-44: +1 .. thanks jakob nit: is %1$ redundant? i had to look up the formatter in java for this :)... i think %010d should be fine? 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 ] Jakob Homan updated ZOOKEEPER-44: - Attachment: seqfile2.diff Unnecessary placeholder removed. 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, seqfile2.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-108) sync implementation reorders operations
[ https://issues.apache.org/jira/browse/ZOOKEEPER-108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Flavio Paiva Junqueira updated ZOOKEEPER-108: - Attachment: SyncTest.java This is the java program that I used to debug this problem. sync implementation reorders operations --- Key: ZOOKEEPER-108 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-108 Project: Zookeeper Issue Type: Bug Components: server Reporter: Flavio Paiva Junqueira Assignee: Flavio Paiva Junqueira Attachments: SyncTest.java, ZOOKEEPER-108.patch The current implementation of sync is broken. There is a race condition that causes a follower to return operations out of order, causing clients to drop their connections to a server. I'll be attaching a patch to fix this problem shortly. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[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 ] Mahadev konar updated ZOOKEEPER-44: --- Resolution: Fixed Status: Resolved (was: Patch Available) I just committed this. THanks Jakob. 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, seqfile2.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.
