[jira] Commented: (ZOOKEEPER-539) generate eclipse project via ant target
[ https://issues.apache.org/jira/browse/ZOOKEEPER-539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12762583#action_12762583 ] Hudson commented on ZOOKEEPER-539: -- Integrated in ZooKeeper-trunk #489 (See [http://hudson.zones.apache.org/hudson/job/ZooKeeper-trunk/489/]) . generate eclipse project via ant target. (phunt via mahadev) generate eclipse project via ant target --- Key: ZOOKEEPER-539 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-539 Project: Zookeeper Issue Type: New Feature Components: build Reporter: Patrick Hunt Assignee: Patrick Hunt Priority: Critical Fix For: 3.3.0 Attachments: ZOOKEEPER-539.patch Enable eclipse project generation via ant target. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-542) c-client can spin when server unresponsive
[ https://issues.apache.org/jira/browse/ZOOKEEPER-542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Reed updated ZOOKEEPER-542: Fix Version/s: 3.3.0 Status: Patch Available (was: Open) c-client can spin when server unresponsive -- Key: ZOOKEEPER-542 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-542 Project: Zookeeper Issue Type: Bug Components: c client Affects Versions: 3.2.0 Reporter: Christian Wiedmann Fix For: 3.3.0 Attachments: ZOOKEEPER-542.patch, ZOOKEEPER-542.patch Due to a mismatch between zookeeper_interest() and zookeeper_process(), when the zookeeper server is unresponsive the client can spin when reconnecting to the server. In particular, zookeeper_interest() adds ZOOKEEPER_WRITE whenever there is data to be sent, but flush_send_queue() only writes the data if the state is ZOO_CONNECTED_STATE. When in ZOO_ASSOCIATING_STATE, this results in spinning. This probably doesn't affect production, but I had a runaway process in a development deployment that caused performance issues on the node. This is easy to reproduce in a single node environment by doing a kill -STOP on the server and waiting for the session timeout. Patch to be added. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-542) c-client can spin when server unresponsive
[ https://issues.apache.org/jira/browse/ZOOKEEPER-542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Reed updated ZOOKEEPER-542: Attachment: ZOOKEEPER-542.patch added comments c-client can spin when server unresponsive -- Key: ZOOKEEPER-542 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-542 Project: Zookeeper Issue Type: Bug Components: c client Affects Versions: 3.2.0 Reporter: Christian Wiedmann Fix For: 3.3.0 Attachments: ZOOKEEPER-542.patch, ZOOKEEPER-542.patch Due to a mismatch between zookeeper_interest() and zookeeper_process(), when the zookeeper server is unresponsive the client can spin when reconnecting to the server. In particular, zookeeper_interest() adds ZOOKEEPER_WRITE whenever there is data to be sent, but flush_send_queue() only writes the data if the state is ZOO_CONNECTED_STATE. When in ZOO_ASSOCIATING_STATE, this results in spinning. This probably doesn't affect production, but I had a runaway process in a development deployment that caused performance issues on the node. This is easy to reproduce in a single node environment by doing a kill -STOP on the server and waiting for the session timeout. Patch to be added. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-542) c-client can spin when server unresponsive
[ https://issues.apache.org/jira/browse/ZOOKEEPER-542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12762696#action_12762696 ] Hadoop QA commented on ZOOKEEPER-542: - -1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12421444/ZOOKEEPER-542.patch against trunk revision 822065. +1 @author. The patch does not contain any @author tags. -1 tests included. The patch doesn't appear to include any new or modified tests. Please justify why no tests are needed for this patch. +1 javadoc. The javadoc tool did not generate any warning messages. +1 javac. The applied patch does not increase the total number of javac compiler warnings. +1 findbugs. The patch does not introduce any new Findbugs warnings. +1 release audit. The applied patch does not increase the total number of release audit warnings. +1 core tests. The patch passed core unit tests. +1 contrib tests. The patch passed contrib unit tests. Test results: http://hudson.zones.apache.org/hudson/job/Zookeeper-Patch-h8.grid.sp2.yahoo.net/17/testReport/ Findbugs warnings: http://hudson.zones.apache.org/hudson/job/Zookeeper-Patch-h8.grid.sp2.yahoo.net/17/artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html Console output: http://hudson.zones.apache.org/hudson/job/Zookeeper-Patch-h8.grid.sp2.yahoo.net/17/console This message is automatically generated. c-client can spin when server unresponsive -- Key: ZOOKEEPER-542 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-542 Project: Zookeeper Issue Type: Bug Components: c client Affects Versions: 3.2.0 Reporter: Christian Wiedmann Fix For: 3.3.0 Attachments: ZOOKEEPER-542.patch, ZOOKEEPER-542.patch Due to a mismatch between zookeeper_interest() and zookeeper_process(), when the zookeeper server is unresponsive the client can spin when reconnecting to the server. In particular, zookeeper_interest() adds ZOOKEEPER_WRITE whenever there is data to be sent, but flush_send_queue() only writes the data if the state is ZOO_CONNECTED_STATE. When in ZOO_ASSOCIATING_STATE, this results in spinning. This probably doesn't affect production, but I had a runaway process in a development deployment that caused performance issues on the node. This is easy to reproduce in a single node environment by doing a kill -STOP on the server and waiting for the session timeout. Patch to be added. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-542) c-client can spin when server unresponsive
[ https://issues.apache.org/jira/browse/ZOOKEEPER-542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Hunt updated ZOOKEEPER-542: --- Affects Version/s: 3.2.1 c-client can spin when server unresponsive -- Key: ZOOKEEPER-542 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-542 Project: Zookeeper Issue Type: Bug Components: c client Affects Versions: 3.2.0, 3.2.1 Reporter: Christian Wiedmann Fix For: 3.3.0 Attachments: ZOOKEEPER-542.patch, ZOOKEEPER-542.patch Due to a mismatch between zookeeper_interest() and zookeeper_process(), when the zookeeper server is unresponsive the client can spin when reconnecting to the server. In particular, zookeeper_interest() adds ZOOKEEPER_WRITE whenever there is data to be sent, but flush_send_queue() only writes the data if the state is ZOO_CONNECTED_STATE. When in ZOO_ASSOCIATING_STATE, this results in spinning. This probably doesn't affect production, but I had a runaway process in a development deployment that caused performance issues on the node. This is easy to reproduce in a single node environment by doing a kill -STOP on the server and waiting for the session timeout. Patch to be added. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-542) c-client can spin when server unresponsive
[ https://issues.apache.org/jira/browse/ZOOKEEPER-542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Hunt updated ZOOKEEPER-542: --- Status: Open (was: Patch Available) Is a test possible here? It would be great to have one to verify the fix. c-client can spin when server unresponsive -- Key: ZOOKEEPER-542 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-542 Project: Zookeeper Issue Type: Bug Components: c client Affects Versions: 3.2.0 Reporter: Christian Wiedmann Fix For: 3.3.0 Attachments: ZOOKEEPER-542.patch, ZOOKEEPER-542.patch Due to a mismatch between zookeeper_interest() and zookeeper_process(), when the zookeeper server is unresponsive the client can spin when reconnecting to the server. In particular, zookeeper_interest() adds ZOOKEEPER_WRITE whenever there is data to be sent, but flush_send_queue() only writes the data if the state is ZOO_CONNECTED_STATE. When in ZOO_ASSOCIATING_STATE, this results in spinning. This probably doesn't affect production, but I had a runaway process in a development deployment that caused performance issues on the node. This is easy to reproduce in a single node environment by doing a kill -STOP on the server and waiting for the session timeout. Patch to be added. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (ZOOKEEPER-542) c-client can spin when server unresponsive
[ https://issues.apache.org/jira/browse/ZOOKEEPER-542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Hunt reassigned ZOOKEEPER-542: -- Assignee: Christian Wiedmann c-client can spin when server unresponsive -- Key: ZOOKEEPER-542 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-542 Project: Zookeeper Issue Type: Bug Components: c client Affects Versions: 3.2.0, 3.2.1 Reporter: Christian Wiedmann Assignee: Christian Wiedmann Fix For: 3.3.0 Attachments: ZOOKEEPER-542.patch, ZOOKEEPER-542.patch Due to a mismatch between zookeeper_interest() and zookeeper_process(), when the zookeeper server is unresponsive the client can spin when reconnecting to the server. In particular, zookeeper_interest() adds ZOOKEEPER_WRITE whenever there is data to be sent, but flush_send_queue() only writes the data if the state is ZOO_CONNECTED_STATE. When in ZOO_ASSOCIATING_STATE, this results in spinning. This probably doesn't affect production, but I had a runaway process in a development deployment that caused performance issues on the node. This is easy to reproduce in a single node environment by doing a kill -STOP on the server and waiting for the session timeout. Patch to be added. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-542) c-client can spin when server unresponsive
[ https://issues.apache.org/jira/browse/ZOOKEEPER-542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12762713#action_12762713 ] Christian Wiedmann commented on ZOOKEEPER-542: -- I don't really know how to do an automated test for this, since the spinning is not visible outside of the API. The manual test I used is to kill -STOP the server and then wait until the client tries to reconnect while running strace on the I/O thread (I'm using python bindings, btw). Pre-patch the strace shows repeated calls to poll, with POLLOUT set on the server fd. Post-patch, POLLOUT is not set, and there is no spinning. c-client can spin when server unresponsive -- Key: ZOOKEEPER-542 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-542 Project: Zookeeper Issue Type: Bug Components: c client Affects Versions: 3.2.0, 3.2.1 Reporter: Christian Wiedmann Assignee: Christian Wiedmann Fix For: 3.3.0 Attachments: ZOOKEEPER-542.patch, ZOOKEEPER-542.patch Due to a mismatch between zookeeper_interest() and zookeeper_process(), when the zookeeper server is unresponsive the client can spin when reconnecting to the server. In particular, zookeeper_interest() adds ZOOKEEPER_WRITE whenever there is data to be sent, but flush_send_queue() only writes the data if the state is ZOO_CONNECTED_STATE. When in ZOO_ASSOCIATING_STATE, this results in spinning. This probably doesn't affect production, but I had a runaway process in a development deployment that caused performance issues on the node. This is easy to reproduce in a single node environment by doing a kill -STOP on the server and waiting for the session timeout. Patch to be added. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-542) c-client can spin when server unresponsive
[ https://issues.apache.org/jira/browse/ZOOKEEPER-542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mahadev konar updated ZOOKEEPER-542: Status: Patch Available (was: Open) making it PA for now... pat agrees that its a hard to test jira.. c-client can spin when server unresponsive -- Key: ZOOKEEPER-542 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-542 Project: Zookeeper Issue Type: Bug Components: c client Affects Versions: 3.2.1, 3.2.0 Reporter: Christian Wiedmann Assignee: Christian Wiedmann Fix For: 3.3.0 Attachments: ZOOKEEPER-542.patch, ZOOKEEPER-542.patch Due to a mismatch between zookeeper_interest() and zookeeper_process(), when the zookeeper server is unresponsive the client can spin when reconnecting to the server. In particular, zookeeper_interest() adds ZOOKEEPER_WRITE whenever there is data to be sent, but flush_send_queue() only writes the data if the state is ZOO_CONNECTED_STATE. When in ZOO_ASSOCIATING_STATE, this results in spinning. This probably doesn't affect production, but I had a runaway process in a development deployment that caused performance issues on the node. This is easy to reproduce in a single node environment by doing a kill -STOP on the server and waiting for the session timeout. Patch to be added. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-542) c-client can spin when server unresponsive
[ https://issues.apache.org/jira/browse/ZOOKEEPER-542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12762724#action_12762724 ] Mahadev konar commented on ZOOKEEPER-542: - +1 for the patch it would be really hard to write a test for this since we would have to have a server in which a connect does not complete (and also does not error out soon)... which can be done via SIGSTOP but would be rather hard to do in a automated test. c-client can spin when server unresponsive -- Key: ZOOKEEPER-542 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-542 Project: Zookeeper Issue Type: Bug Components: c client Affects Versions: 3.2.0, 3.2.1 Reporter: Christian Wiedmann Assignee: Christian Wiedmann Fix For: 3.3.0 Attachments: ZOOKEEPER-542.patch, ZOOKEEPER-542.patch Due to a mismatch between zookeeper_interest() and zookeeper_process(), when the zookeeper server is unresponsive the client can spin when reconnecting to the server. In particular, zookeeper_interest() adds ZOOKEEPER_WRITE whenever there is data to be sent, but flush_send_queue() only writes the data if the state is ZOO_CONNECTED_STATE. When in ZOO_ASSOCIATING_STATE, this results in spinning. This probably doesn't affect production, but I had a runaway process in a development deployment that caused performance issues on the node. This is easy to reproduce in a single node environment by doing a kill -STOP on the server and waiting for the session timeout. Patch to be added. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (ZOOKEEPER-543) Tests for ZooKeeper examples
Tests for ZooKeeper examples Key: ZOOKEEPER-543 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-543 Project: Zookeeper Issue Type: New Feature Components: tests Affects Versions: 3.3.0 Reporter: Steven Cheng Priority: Minor Fix For: 3.3.0 Initial attempt to create ZooKeeper tests based on the example code on the website. Current plan is to test features used in examples using ZooKeeper calls directly. Another approach would be to make more usable abstractions such as those in src/recipes and test those. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-543) Tests for ZooKeeper examples
[ https://issues.apache.org/jira/browse/ZOOKEEPER-543?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steven Cheng updated ZOOKEEPER-543: --- Attachment: ZOOKEEPER-543.patch Tests for ZooKeeper examples Key: ZOOKEEPER-543 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-543 Project: Zookeeper Issue Type: New Feature Components: tests Affects Versions: 3.3.0 Reporter: Steven Cheng Priority: Minor Fix For: 3.3.0 Attachments: ZOOKEEPER-543.patch Initial attempt to create ZooKeeper tests based on the example code on the website. Current plan is to test features used in examples using ZooKeeper calls directly. Another approach would be to make more usable abstractions such as those in src/recipes and test those. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-541) zkpython limited to 256 handles
[ https://issues.apache.org/jira/browse/ZOOKEEPER-541?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henry Robinson updated ZOOKEEPER-541: - Attachment: ZOOKEEPER-541.patch This patch ups the limit of concurrently active connections to 32768, and allocates these handles dynamically in increasing powers of two. Handles are re-used when they are correctly closed. This involves an O(n) scan of the handle array, but I think this is preferable to the overhead of managing linked lists with O(1) lookup. Tests are included. zkpython limited to 256 handles --- Key: ZOOKEEPER-541 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-541 Project: Zookeeper Issue Type: Bug Components: contrib-bindings Affects Versions: 3.2.1 Reporter: Patrick Hunt Assignee: Henry Robinson Fix For: 3.3.0 Attachments: ZOOKEEPER-541.patch zkpython is currently limited to a max of 256 total handles - not 256 open handles, but rather 256 total handles created over the lifetime of the python application. In general this isn't a real issue, however in the case of a long lived application which polls the cluster periodically (closing the session btw calls) this is an issue. it would be great if the slots could be reused? or perhaps a more complex structure, such as a linked list, which would allow dynamic growth/shrinkage of the handle list. Also see ZOOKEEPER-540 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-541) zkpython limited to 256 handles
[ https://issues.apache.org/jira/browse/ZOOKEEPER-541?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henry Robinson updated ZOOKEEPER-541: - Status: Patch Available (was: Open) zkpython limited to 256 handles --- Key: ZOOKEEPER-541 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-541 Project: Zookeeper Issue Type: Bug Components: contrib-bindings Affects Versions: 3.2.1 Reporter: Patrick Hunt Assignee: Henry Robinson Fix For: 3.3.0 Attachments: ZOOKEEPER-541.patch zkpython is currently limited to a max of 256 total handles - not 256 open handles, but rather 256 total handles created over the lifetime of the python application. In general this isn't a real issue, however in the case of a long lived application which polls the cluster periodically (closing the session btw calls) this is an issue. it would be great if the slots could be reused? or perhaps a more complex structure, such as a linked list, which would allow dynamic growth/shrinkage of the handle list. Also see ZOOKEEPER-540 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-510) zkpython lumps all exceptions as IOError, needs specialized exceptions for KeeperException types
[ https://issues.apache.org/jira/browse/ZOOKEEPER-510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12762804#action_12762804 ] Hadoop QA commented on ZOOKEEPER-510: - +1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12421360/ZOOKEEPER-510.patch against trunk revision 822065. +1 @author. The patch does not contain any @author tags. +1 tests included. The patch appears to include 25 new or modified tests. +1 javadoc. The javadoc tool did not generate any warning messages. +1 javac. The applied patch does not increase the total number of javac compiler warnings. +1 findbugs. The patch does not introduce any new Findbugs warnings. +1 release audit. The applied patch does not increase the total number of release audit warnings. +1 core tests. The patch passed core unit tests. +1 contrib tests. The patch passed contrib unit tests. Test results: http://hudson.zones.apache.org/hudson/job/Zookeeper-Patch-h8.grid.sp2.yahoo.net/19/testReport/ Findbugs warnings: http://hudson.zones.apache.org/hudson/job/Zookeeper-Patch-h8.grid.sp2.yahoo.net/19/artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html Console output: http://hudson.zones.apache.org/hudson/job/Zookeeper-Patch-h8.grid.sp2.yahoo.net/19/console This message is automatically generated. zkpython lumps all exceptions as IOError, needs specialized exceptions for KeeperException types Key: ZOOKEEPER-510 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-510 Project: Zookeeper Issue Type: Bug Components: contrib-bindings Affects Versions: 3.2.0 Reporter: Patrick Hunt Assignee: Henry Robinson Fix For: 3.3.0 Attachments: ZOOKEEPER-510.patch, ZOOKEEPER-510.patch, ZOOKEEPER-510.patch, ZOOKEEPER-510.patch The current zkpython bindings always throw IOError(text) exceptions, even for ZK specific exceptions such as NODEEXISTS. This makes it difficult (error prone) to handle exceptions in python code. You can't easily pickup a connection loss vs a node exists for example. Of course you could match the error string, but this seems like a bad idea imo. We need to add specific exception types to the python binding that map directly to KeeperException/java types. It would also be useful to include the information provided by the KeeperException (like path in some cases), etc... as part of the error thrown to the python code. Would probably be a good idea to stay as close to java api as possible wrt mapping the errors. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-543) Tests for ZooKeeper examples
[ https://issues.apache.org/jira/browse/ZOOKEEPER-543?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12762807#action_12762807 ] Steven Cheng commented on ZOOKEEPER-543: There's a bug in the node name processing, it tries to remove the full path from the string before parsing the id. The test still passes because of the 0 padding on the names. I'll fix this. Tests for ZooKeeper examples Key: ZOOKEEPER-543 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-543 Project: Zookeeper Issue Type: New Feature Components: tests Affects Versions: 3.3.0 Reporter: Steven Cheng Priority: Minor Fix For: 3.3.0 Attachments: ZOOKEEPER-543.patch Initial attempt to create ZooKeeper tests based on the example code on the website. Current plan is to test features used in examples using ZooKeeper calls directly. Another approach would be to make more usable abstractions such as those in src/recipes and test those. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-543) Tests for ZooKeeper examples
[ https://issues.apache.org/jira/browse/ZOOKEEPER-543?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steven Cheng updated ZOOKEEPER-543: --- Attachment: ZOOKEEPER-543.patch Tests for ZooKeeper examples Key: ZOOKEEPER-543 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-543 Project: Zookeeper Issue Type: New Feature Components: tests Affects Versions: 3.3.0 Reporter: Steven Cheng Priority: Minor Fix For: 3.3.0 Attachments: ZOOKEEPER-543.patch Initial attempt to create ZooKeeper tests based on the example code on the website. Current plan is to test features used in examples using ZooKeeper calls directly. Another approach would be to make more usable abstractions such as those in src/recipes and test those. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-543) Tests for ZooKeeper examples
[ https://issues.apache.org/jira/browse/ZOOKEEPER-543?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steven Cheng updated ZOOKEEPER-543: --- Attachment: (was: ZOOKEEPER-543.patch) Tests for ZooKeeper examples Key: ZOOKEEPER-543 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-543 Project: Zookeeper Issue Type: New Feature Components: tests Affects Versions: 3.3.0 Reporter: Steven Cheng Priority: Minor Fix For: 3.3.0 Attachments: ZOOKEEPER-543.patch Initial attempt to create ZooKeeper tests based on the example code on the website. Current plan is to test features used in examples using ZooKeeper calls directly. Another approach would be to make more usable abstractions such as those in src/recipes and test those. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-541) zkpython limited to 256 handles
[ https://issues.apache.org/jira/browse/ZOOKEEPER-541?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12762839#action_12762839 ] Henry Robinson commented on ZOOKEEPER-541: -- This patch requires ZOOKEEPER-510 to be committed. zkpython limited to 256 handles --- Key: ZOOKEEPER-541 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-541 Project: Zookeeper Issue Type: Bug Components: contrib-bindings Affects Versions: 3.2.1 Reporter: Patrick Hunt Assignee: Henry Robinson Fix For: 3.3.0 Attachments: ZOOKEEPER-541.patch zkpython is currently limited to a max of 256 total handles - not 256 open handles, but rather 256 total handles created over the lifetime of the python application. In general this isn't a real issue, however in the case of a long lived application which polls the cluster periodically (closing the session btw calls) this is an issue. it would be great if the slots could be reused? or perhaps a more complex structure, such as a linked list, which would allow dynamic growth/shrinkage of the handle list. Also see ZOOKEEPER-540 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
