[jira] Commented: (ZOOKEEPER-661) Add Ruby bindings
[ https://issues.apache.org/jira/browse/ZOOKEEPER-661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12836239#action_12836239 ] Andrew Reynhout commented on ZOOKEEPER-661: --- Looks like emaland forked the old myelin code. We looked at that, but ultimately decided to start over using Ruby FFI. Also, it doesn't look like they've done async calls and watchers yet, but maybe I missed it. Asynchronous calls were never high priority for my use case, but watchers were essential. Both ran into the same threading problems though, so I ended up using the same workarounds. I've been a bit distracted for the last few weeks, so I haven't made any progress on the MT vs ST idea. I've moved all of the code into a public github repo, so if it's useful please check it out. http://github.com/ce/ruby-zookeeper > Add Ruby bindings > - > > Key: ZOOKEEPER-661 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-661 > Project: Zookeeper > Issue Type: New Feature > Components: contrib-bindings > Environment: MRI Ruby 1.9 > JRuby 1.4 >Reporter: Andrew Reynhout >Priority: Minor > > Add Ruby bindings to the ZooKeeper distribution. > Ruby presents special threading difficulties for asynchronous ZK calls (aget, > watchers, etc). It looks like the simplest workaround is to patch the ZK C > API. > Proposed approach will be described in comment. > Please use this ticket for discussion and suggestions. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-675) LETest thread fails to join
[ https://issues.apache.org/jira/browse/ZOOKEEPER-675?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Flavio Paiva Junqueira updated ZOOKEEPER-675: - Description: After applying the patch of ZOOKEEPER-569, I observed a failure of LETest. From a cursory inspection of the log, I can tell that a leader is being elected, but some thread is not joining. At this point I'm not sure if this is a problem with the leader election implementation or the test itself. Just to be clear, the patch of ZOOKEEPER-569 solved a real issue, but it seems that there is yet another problem with LETest. was: After applying the patch of ZOOKEEPER-569, I observed a failure of LETest. From a cursory inspection of the log, I can tell that a leader is being elected, but some thread is not joining. I'm not sure Just to be clear, the patch of ZOOKEEPER-569 solved a real issue, but it seems that there is yet another problem with LETest. > LETest thread fails to join > --- > > Key: ZOOKEEPER-675 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-675 > Project: Zookeeper > Issue Type: Bug > Components: leaderElection >Reporter: Flavio Paiva Junqueira > Fix For: 3.4.0 > > Attachments: TEST-org.apache.zookeeper.test.LETest.txt > > > After applying the patch of ZOOKEEPER-569, I observed a failure of LETest. > From a cursory inspection of the log, I can tell that a leader is being > elected, but some thread is not joining. At this point I'm not sure if this > is a problem with the leader election implementation or the test itself. > Just to be clear, the patch of ZOOKEEPER-569 solved a real issue, but it > seems that there is yet another problem with LETest. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-675) LETest thread fails to join
[ https://issues.apache.org/jira/browse/ZOOKEEPER-675?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Flavio Paiva Junqueira updated ZOOKEEPER-675: - Attachment: TEST-org.apache.zookeeper.test.LETest.txt > LETest thread fails to join > --- > > Key: ZOOKEEPER-675 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-675 > Project: Zookeeper > Issue Type: Bug > Components: leaderElection >Reporter: Flavio Paiva Junqueira > Fix For: 3.4.0 > > Attachments: TEST-org.apache.zookeeper.test.LETest.txt > > > After applying the patch of ZOOKEEPER-569, I observed a failure of LETest. > From a cursory inspection of the log, I can tell that a leader is being > elected, but some thread is not joining. I'm not sure > Just to be clear, the patch of ZOOKEEPER-569 solved a real issue, but it > seems that there is yet another problem with LETest. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (ZOOKEEPER-675) LETest thread fails to join
LETest thread fails to join --- Key: ZOOKEEPER-675 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-675 Project: Zookeeper Issue Type: Bug Components: leaderElection Reporter: Flavio Paiva Junqueira Fix For: 3.4.0 After applying the patch of ZOOKEEPER-569, I observed a failure of LETest. From a cursory inspection of the log, I can tell that a leader is being elected, but some thread is not joining. I'm not sure Just to be clear, the patch of ZOOKEEPER-569 solved a real issue, but it seems that there is yet another problem with LETest. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-569) Failure of elected leader can lead to never-ending leader election
[ https://issues.apache.org/jira/browse/ZOOKEEPER-569?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Flavio Paiva Junqueira updated ZOOKEEPER-569: - Resolution: Fixed Status: Resolved (was: Patch Available) +1, thanks Henry! I have just committed it (Committed revision 912119). > Failure of elected leader can lead to never-ending leader election > -- > > Key: ZOOKEEPER-569 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-569 > Project: Zookeeper > Issue Type: Bug >Reporter: Henry Robinson >Assignee: Henry Robinson > Fix For: 3.3.0 > > Attachments: zookeeper-569.patch, ZOOKEEPER-569.patch, > zookeeper-569.patch, zookeeper-569.patch, zookeeper-569.patch, > zookeeper-569.patch > > > It is possible for basic LeaderElection to enter a situation where it never > terminates. > As an example, consider a three node cluster A, B and C. > 1. In the first round, A votes for A, B votes for B and C votes for C > 2. Since C > B > A, all nodes resolve to vote for C in the second round as > there is no first round winner > 3. A, B vote for C, but C fails. > 4. C is not elected because neither A nor B hear from it, and so votes for it > are discarded > 5. A and B never reset their votes, despite not hearing from C, so continue > to vote for it ad infinitum. > Step 5 is the bug. If A and B reset their votes to themselves in the case > where the heard-from vote set is empty, leader election will continue. > I do not know if this affects running ZK clusters, as it is possible that the > out-of-band failure detection protocols may cause leader election to be > restarted anyhow, but I've certainly seen this in tests. > I have a trivial patch which fixes it, but it needs a test (and tests for > race conditions are hard to write!) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-524) DBSizeTest is not really testing anything
[ https://issues.apache.org/jira/browse/ZOOKEEPER-524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12836149#action_12836149 ] Hudson commented on ZOOKEEPER-524: -- Integrated in ZooKeeper-trunk #702 (See [http://hudson.zones.apache.org/hudson/job/ZooKeeper-trunk/702/]) . DBSizeTest is not really testing anything > DBSizeTest is not really testing anything > - > > Key: ZOOKEEPER-524 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-524 > Project: Zookeeper > Issue Type: Bug > Components: server, tests >Reporter: Patrick Hunt >Assignee: Benjamin Reed >Priority: Minor > Fix For: 3.3.0 > > > DBSizeTest looks like it should be testing latency, but it doesn't seem to do > it (assert is commented out). > We need to decide if this test should be fixed, or just dropped. > Also note: this test takes 40seconds on my system. Way too long. Perhaps > async create operations should be used > to populate the database. I also noticed that data size has a big impact on > overall test time (1k vs 5 bytes is something > like a 2x time diff for time to run the test). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
