[jira] Updated: (ZOOKEEPER-622) Test for pending watches in send_set_watches should be moved
[
https://issues.apache.org/jira/browse/ZOOKEEPER-622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steven Cheng updated ZOOKEEPER-622:
---
Attachment: ZOOKEEPER-622.patch
A working test case for watch transfer with multiple hosts. I left testScript
in there because it is quite useful for basic sanity testing for the scripts.
Test for pending watches in send_set_watches should be moved
Key: ZOOKEEPER-622
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-622
Project: Zookeeper
Issue Type: Bug
Components: c client
Reporter: Steven Cheng
Assignee: Benjamin Reed
Fix For: 3.3.0
Attachments: ZOOKEEPER-622.patch, ZOOKEEPER-622.patch,
ZOOKEEPER-622.patch
Valgrind found:
{quote}
==2357== Conditional jump or move depends on uninitialised value(s)
==2357==at 0x807FDCA: check_events (zookeeper.c:1180)
==2357==by 0x808043A: zookeeper_process (zookeeper.c:1775)
==2357==by 0x806A21B: Zookeeper_close::testCloseConnected1()
(TestZookeeperClose.cc:161)
==2357==by 0x806C6BF: CppUnit::TestCallerZookeeper_close::runTest()
(TestCaller.h:166)
{quote}
zookeeper.c:1180 was the first if in send_set_watches.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-622) Test for pending watches in send_set_watches should be moved
[
https://issues.apache.org/jira/browse/ZOOKEEPER-622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12837139#action_12837139
]
Steven Cheng commented on ZOOKEEPER-622:
This patch works but is still in rough shape! The multi host test servers are
started on separate ports and are running concurrently with the single host
test server. Would be helpful to make this more clear.
Paths still hardcoded to /tmp.
zooX.cfg are in the patch but are generated by generateCfgs.sh
I encountered a ZCONNECTIONLOSS from an operation executed after the client
reconnects to a new host. Adds an awkward section to the test case. I guess
in some sense the client should not be oblivious to one of these lucky
disconnect/reconnect situations.
Test for pending watches in send_set_watches should be moved
Key: ZOOKEEPER-622
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-622
Project: Zookeeper
Issue Type: Bug
Components: c client
Reporter: Steven Cheng
Assignee: Benjamin Reed
Fix For: 3.3.0
Attachments: ZOOKEEPER-622.patch, ZOOKEEPER-622.patch,
ZOOKEEPER-622.patch
Valgrind found:
{quote}
==2357== Conditional jump or move depends on uninitialised value(s)
==2357==at 0x807FDCA: check_events (zookeeper.c:1180)
==2357==by 0x808043A: zookeeper_process (zookeeper.c:1775)
==2357==by 0x806A21B: Zookeeper_close::testCloseConnected1()
(TestZookeeperClose.cc:161)
==2357==by 0x806C6BF: CppUnit::TestCallerZookeeper_close::runTest()
(TestCaller.h:166)
{quote}
zookeeper.c:1180 was the first if in send_set_watches.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (ZOOKEEPER-677) c client doesn't allow ipv6 numeric connect string
[ https://issues.apache.org/jira/browse/ZOOKEEPER-677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mahadev konar reassigned ZOOKEEPER-677: --- Assignee: Benjamin Reed c client doesn't allow ipv6 numeric connect string -- Key: ZOOKEEPER-677 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-677 Project: Zookeeper Issue Type: Bug Components: c client Affects Versions: 3.2.2 Reporter: Patrick Hunt Assignee: Benjamin Reed Priority: Critical Fix For: 3.3.0 Attachments: ZOOKEEPER-677.patch The c client doesn't handle ipv6 numeric addresses as they are colon : delmited. After splitting the host/port on : we look for the port as the second entry in the array rather than the last entry in the array. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-669) watchedevent tostring should clearly output the state/type/path
[ https://issues.apache.org/jira/browse/ZOOKEEPER-669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mahadev konar updated ZOOKEEPER-669: Resolution: Fixed Hadoop Flags: [Reviewed] Status: Resolved (was: Patch Available) I just committed this. thanks pat! watchedevent tostring should clearly output the state/type/path --- Key: ZOOKEEPER-669 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-669 Project: Zookeeper Issue Type: Bug Affects Versions: 3.1.2, 3.2.2 Reporter: Patrick Hunt Assignee: Patrick Hunt Priority: Critical Fix For: 3.3.0 Attachments: ZOOKEEPER-669.patch the current tostring method is broken -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-642) exceeded deadline by N ms floods logs
[ https://issues.apache.org/jira/browse/ZOOKEEPER-642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12837457#action_12837457 ] Lei Zhang commented on ZOOKEEPER-642: - I have taken over Dale's responsibility of zookeeper. We have bumped up tickTime to 2 per Patrick's suggestion in another thread. Now we see these Exceeded deadline by 769ms message every 10 seconds - I'm testing using 'cli_st localhost:port', on a VMware Linux machine that is mostly idle . I echo Dale's comment: The message as it is has a fairly low diagnostic value. Since this message is at WARN level, I feel we need to do something. But what: o bump up priority of zookeeper daemon o check bug in client library o check bug in zookeeper server Somehow this doesn't smell like a real Exceeded timeline issue to me. exceeded deadline by N ms floods logs --- Key: ZOOKEEPER-642 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-642 Project: Zookeeper Issue Type: Bug Components: c client Affects Versions: 3.2.1 Environment: virtualized linux - ec2 - ubuntu Reporter: Dale Johnson Fix For: 3.4.0 More important zookeeper warnings are drown out by the following several times per minute: 2010-01-12 17:39:57,227:22317(0x4147eb90):zoo_w...@zookeeper_interest@1335: Exceeded deadline by 13ms Perhaps this is an issue with the way virtualized systems manage gettimeofday results? Maybe the current 10ms threshold could be pushed up a bit. I notice that 95% of the messages are below 50ms. Is there an obvious configuration change that I can make to fix this? config file below: # The number of milliseconds of each tick tickTime=2000 # The number of ticks that the initial # synchronization phase can take initLimit=10 # The number of ticks that can pass between # sending a request and getting an acknowledgement syncLimit=5 # the directory where the snapshot is stored. dataDir=/mnt/zookeeper # the port at which the clients will connect clientPort=2181 server.1=hbase.1:2888:3888 server.2=hbase.2:2888:3888 server.3=hbase.3:2888:3888 server.4=hbase.4:2888:3888 server.5=hbase.5:2888:3888 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-642) exceeded deadline by N ms floods logs
[ https://issues.apache.org/jira/browse/ZOOKEEPER-642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12837493#action_12837493 ] Patrick Hunt commented on ZOOKEEPER-642: We have bumped up tickTime to 2 per Patrick's suggestion in another thread. Hm, I'm not sure which thread you are referring to but tickTime has no impact on this particular issue. Exceeded deadline by 769ms ... The message as it is has a fairly low diagnostic value. I don't think that's the case here. Nearly 800ms is a pretty significant issue, esp as the vm is unloaded as you mentioned. Can you try using cli_mt instead of cli_st and see if you notice any difference? This message Exceeded deadline by 769ms is saying that the ZK _client_ asked the operating system, via the select(..., timeout) call, to either select something or wakeup after the specified timeout. From the select man page: timeout is an upper bound on the amount of time elapsed before select() returns. We are printing this message because select woke up 769ms later than what we asked, which is pretty significant. Notice this has nothing to do with the server, server settings/config or server performance, it's all local to the client/select call. This tells me that something is up on your client, prolly due to use of vmware. Perhaps Swapping at the host (non-virt) level? Try the cli_mt, you might also try running w/o VMware and see what happens, it will give you a baseline. exceeded deadline by N ms floods logs --- Key: ZOOKEEPER-642 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-642 Project: Zookeeper Issue Type: Bug Components: c client Affects Versions: 3.2.1 Environment: virtualized linux - ec2 - ubuntu Reporter: Dale Johnson Fix For: 3.4.0 More important zookeeper warnings are drown out by the following several times per minute: 2010-01-12 17:39:57,227:22317(0x4147eb90):zoo_w...@zookeeper_interest@1335: Exceeded deadline by 13ms Perhaps this is an issue with the way virtualized systems manage gettimeofday results? Maybe the current 10ms threshold could be pushed up a bit. I notice that 95% of the messages are below 50ms. Is there an obvious configuration change that I can make to fix this? config file below: # The number of milliseconds of each tick tickTime=2000 # The number of ticks that the initial # synchronization phase can take initLimit=10 # The number of ticks that can pass between # sending a request and getting an acknowledgement syncLimit=5 # the directory where the snapshot is stored. dataDir=/mnt/zookeeper # the port at which the clients will connect clientPort=2181 server.1=hbase.1:2888:3888 server.2=hbase.2:2888:3888 server.3=hbase.3:2888:3888 server.4=hbase.4:2888:3888 server.5=hbase.5:2888:3888 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-678) Browser application to view and edit the contents of a zookeeper instance
[ https://issues.apache.org/jira/browse/ZOOKEEPER-678?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Hunt updated ZOOKEEPER-678: --- Assignee: Colin Goodheart-Smithe Browser application to view and edit the contents of a zookeeper instance - Key: ZOOKEEPER-678 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-678 Project: Zookeeper Issue Type: New Feature Affects Versions: 3.3.0 Reporter: Colin Goodheart-Smithe Assignee: Colin Goodheart-Smithe Fix For: 3.3.0 Attachments: ZooInspector.zip An application which shows a tree view of the nodes currently in a zookeeper instance and allow the user to view and update the contents of the nodes as well as allowing users to add and remove nodes from the tree, similar in use to the Luke application in the Lucene project. I have a list of other features that I want to add to this application but I wanted to gauge the response before I implemented them all. I have found this useful when debugging my application and thought that it may be useful to others. I was going to submit this as a patch file but I have used some icon files and one library which isn't available in the maven/ivy repositories and these don't seem to work when creating a patch file using subversion. Because of this I have attached a zip containing this application to this issue. If there is a better way to submit this please let me know. The zip contains two directories, the src directory contains the source as it would be added to the contrib folder and the build folder contains a build version of the with a runnable jar. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-22) Automatic request retries on connect failover
[ https://issues.apache.org/jira/browse/ZOOKEEPER-22?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Hunt updated ZOOKEEPER-22: -- Fix Version/s: (was: 3.3.0) 3.4.0 Automatic request retries on connect failover - Key: ZOOKEEPER-22 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-22 Project: Zookeeper Issue Type: New Feature Components: c client, java client Reporter: Patrick Hunt Assignee: Mahadev konar Fix For: 3.4.0 Attachments: zookeeper-22.docx, zookeeper-22.pdf Moved from SourceForge to Apache. http://sourceforge.net/tracker/index.php?func=detailaid=1831412group_id=209147atid=1008547 When a connection to a ZooKeeper server fails, all of the pending requests will return an error. In reality the requests should be resubmitted when the client reestablishes a connection to ZooKeeper. For read requests, it's no big deal to just reissue the request. For update requests, the ZooKeeper must be able to detect if the request has been processed and, if so, return the result of the previous execution; otherwise, it should process the 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-642) exceeded deadline by N ms floods logs
[ https://issues.apache.org/jira/browse/ZOOKEEPER-642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12837506#action_12837506 ] Lei Zhang commented on ZOOKEEPER-642: - Maybe I had misinterpreted what you meant by timeout - I was referring to http://mail-archives.apache.org/mod_mbox/hadoop-zookeeper-user/200908.mbox/%253c4a8d7b4b.5020...@apache.org%253e . typically we suggest timeouts in the 20-30 second range Same. Still seeing same message every 10 seconds. exceeded deadline by N ms floods logs --- Key: ZOOKEEPER-642 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-642 Project: Zookeeper Issue Type: Bug Components: c client Affects Versions: 3.2.1 Environment: virtualized linux - ec2 - ubuntu Reporter: Dale Johnson Fix For: 3.4.0 More important zookeeper warnings are drown out by the following several times per minute: 2010-01-12 17:39:57,227:22317(0x4147eb90):zoo_w...@zookeeper_interest@1335: Exceeded deadline by 13ms Perhaps this is an issue with the way virtualized systems manage gettimeofday results? Maybe the current 10ms threshold could be pushed up a bit. I notice that 95% of the messages are below 50ms. Is there an obvious configuration change that I can make to fix this? config file below: # The number of milliseconds of each tick tickTime=2000 # The number of ticks that the initial # synchronization phase can take initLimit=10 # The number of ticks that can pass between # sending a request and getting an acknowledgement syncLimit=5 # the directory where the snapshot is stored. dataDir=/mnt/zookeeper # the port at which the clients will connect clientPort=2181 server.1=hbase.1:2888:3888 server.2=hbase.2:2888:3888 server.3=hbase.3:2888:3888 server.4=hbase.4:2888:3888 server.5=hbase.5:2888:3888 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-678) Browser application to view and edit the contents of a zookeeper instance
[ https://issues.apache.org/jira/browse/ZOOKEEPER-678?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12837536#action_12837536 ] Patrick Hunt commented on ZOOKEEPER-678: Hi Colin, thanks for the submission, I'm looking at it now. I was able to build and run it. Pretty slick - I'm navigating my znode tree just fine. Great! A few issues/comments that I noticed, things that would have to be cleaned up: The zip file is fine. You might just attach updates w/o the build dir, use svn export so that you don't also put the .svn dirs into the zip. Can you add a README.txt to your src directory? After all your hard work it would be good to have some basic detail on what the project is, who wrote it (you) and how to build/run it. It doesn't need to be a tome, just basic information for someone to get up to speed quickly. I noticed you use TableLayout, this is not compatible with Apache licensing. Is it possible to use something else? See this thread for a prior discussion re tablelayout in apache that I found: http://www.mail-archive.com/debian-le...@lists.debian.org/msg40009.html jtoaster is ok - it uses apache 2.0 license. The icons are EPL licensed right? I think it would be a good idea to include a NOTICE.txt (see what I did for CDDL in the rest contrib). Your about box has this, but it would be good to have a NOTICE.txt as well. We don't allow @author tags in the javacode, see making changes: http://wiki.apache.org/hadoop/ZooKeeper/HowToContribute Also, would you be able to use std apache license headers on the source files themselves? If you look at any of the other java files currently in ZooKeeper svn you will see what I'm talking about. You can explicitly list yourself as the originator/author in the README I mentioned. Would that be acceptable to you? Thanks for the submission! Browser application to view and edit the contents of a zookeeper instance - Key: ZOOKEEPER-678 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-678 Project: Zookeeper Issue Type: New Feature Affects Versions: 3.3.0 Reporter: Colin Goodheart-Smithe Assignee: Colin Goodheart-Smithe Fix For: 3.3.0 Attachments: ZooInspector.zip An application which shows a tree view of the nodes currently in a zookeeper instance and allow the user to view and update the contents of the nodes as well as allowing users to add and remove nodes from the tree, similar in use to the Luke application in the Lucene project. I have a list of other features that I want to add to this application but I wanted to gauge the response before I implemented them all. I have found this useful when debugging my application and thought that it may be useful to others. I was going to submit this as a patch file but I have used some icon files and one library which isn't available in the maven/ivy repositories and these don't seem to work when creating a patch file using subversion. Because of this I have attached a zip containing this application to this issue. If there is a better way to submit this please let me know. The zip contains two directories, the src directory contains the source as it would be added to the contrib folder and the build folder contains a build version of the with a runnable jar. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-642) exceeded deadline by N ms floods logs
[ https://issues.apache.org/jira/browse/ZOOKEEPER-642?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12837543#action_12837543 ] Patrick Hunt commented on ZOOKEEPER-642: Hi Lei, tickTime is used by the servers, not really impacts the clients the clients have a timeout value they use when connecting to the servers, this establishes the session timeout. What I was suggesting on the link you listed was changing the timeout, not the tickTime. 2 sec is pretty low for timeout. However in your case none of this matters. The deadline exceeded message you are seeing is purely an OS issue. 1) we select(..., deadline) 2) when we wake up from select we check how close we are to the deadline, if this is exceeded by 10ms then we log a warning. In your case the deadline is being exceeded by a significant amount, this is a warning because it could impact the ability of the client to maintain connectivity with the server. exceeded deadline by N ms floods logs --- Key: ZOOKEEPER-642 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-642 Project: Zookeeper Issue Type: Bug Components: c client Affects Versions: 3.2.1 Environment: virtualized linux - ec2 - ubuntu Reporter: Dale Johnson Fix For: 3.4.0 More important zookeeper warnings are drown out by the following several times per minute: 2010-01-12 17:39:57,227:22317(0x4147eb90):zoo_w...@zookeeper_interest@1335: Exceeded deadline by 13ms Perhaps this is an issue with the way virtualized systems manage gettimeofday results? Maybe the current 10ms threshold could be pushed up a bit. I notice that 95% of the messages are below 50ms. Is there an obvious configuration change that I can make to fix this? config file below: # The number of milliseconds of each tick tickTime=2000 # The number of ticks that the initial # synchronization phase can take initLimit=10 # The number of ticks that can pass between # sending a request and getting an acknowledgement syncLimit=5 # the directory where the snapshot is stored. dataDir=/mnt/zookeeper # the port at which the clients will connect clientPort=2181 server.1=hbase.1:2888:3888 server.2=hbase.2:2888:3888 server.3=hbase.3:2888:3888 server.4=hbase.4:2888:3888 server.5=hbase.5:2888:3888 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-661) Add Ruby bindings
[ https://issues.apache.org/jira/browse/ZOOKEEPER-661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12837572#action_12837572 ] Andrew Reynhout commented on ZOOKEEPER-661: --- Patrick, I agree on the collaboration recommendation. I haven't had a chance to go through all of the changes in Eric's fork yet, so I'm not sure how the two attempts compare in terms of functional completeness. I'll get in touch with Eric and Evan and see how they feel. The primary difference in the two approaches is that we're using FFI and they are using a straight C extension. FFI should make it simpler to keep up with any ZK API changes, and make the code more conveniently portable to JRuby and other platforms, but that might not be a big deal -- ZK is at 3.3, and the C API has been pretty stable. Re: ASF vs github, I think it'd be great to have Ruby bindings in the official distribution, as soon as the bindings are worthy. Github and rubygems definitely make it easier to iterate on the bindings independently of the ZK/ASF release process, but theoretically at some point the bindings will catch up and ZK changes will drive the binding iterations. Thanks, Andrew 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.
