[jira] Commented: (ZOOKEEPER-358) Throw exception when ledger does not exist
[ https://issues.apache.org/jira/browse/ZOOKEEPER-358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12714312#action_12714312 ] Mahadev konar commented on ZOOKEEPER-358: - flavio, was this patch included in ZOOKEEPER-383? > Throw exception when ledger does not exist > -- > > Key: ZOOKEEPER-358 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-358 > Project: Zookeeper > Issue Type: Improvement > Components: contrib-bookkeeper >Affects Versions: 3.1.1 >Reporter: Luca Telloli >Assignee: Flavio Paiva Junqueira >Priority: Minor > Attachments: ZOOKEEPER-358.patch > > > Currently, openLedger() in the BookKeeper client returns null if the ledger > ID does not exist on ZK. Maybe it would be better to throw a specific > exception so it can be handled by the client side. -- 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 ] Benjamin Reed updated ZOOKEEPER-22: --- Description: Moved from SourceForge to Apache. http://sourceforge.net/tracker/index.php?func=detail&aid=1831412&group_id=209147&atid=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. was: Moved from SourceForge to Apache. http://sourceforge.net/tracker/index.php?func=detail&aid=1831412&group_id=209147&atid=1008547 it turns out that all the information to do this is split between server and client. the server pushes all updates through the atomic broadcast, even errors. so if the client resends the pending requests to the server when it reconnects, the server should be able to either replay the responses or execute the request. this would eliminate the annoying-to-deal-with CONNECTIONLOSS error. > 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 > > Moved from SourceForge to Apache. > http://sourceforge.net/tracker/index.php?func=detail&aid=1831412&group_id=209147&atid=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] Assigned: (ZOOKEEPER-237) Add a Chroot request
[ https://issues.apache.org/jira/browse/ZOOKEEPER-237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Hunt reassigned ZOOKEEPER-237: -- Assignee: Patrick Hunt > Add a Chroot request > > > Key: ZOOKEEPER-237 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-237 > Project: Zookeeper > Issue Type: New Feature > Components: c client, java client, server >Reporter: Benjamin Reed >Assignee: Patrick Hunt >Priority: Minor > Fix For: 3.2.0 > > > 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] Assigned: (ZOOKEEPER-327) document effects (latency) of storing large amounts of data in znodes
[ https://issues.apache.org/jira/browse/ZOOKEEPER-327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Hunt reassigned ZOOKEEPER-327: -- Assignee: Benjamin Reed > document effects (latency) of storing large amounts of data in znodes > - > > Key: ZOOKEEPER-327 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-327 > Project: Zookeeper > Issue Type: Improvement > Components: documentation >Reporter: Patrick Hunt >Assignee: Benjamin Reed >Priority: Minor > Fix For: 3.2.0 > > > znodes have max 1mb of data storage. using zk to store large amounts of data > can negatively impact latency as seen by clients - the server needs to serve > the data. often it's a better idea to store a "token" (say a uri) in the > znode pointing to a large data block stored elsewhere (filesystem? memcached, > etc...) this offloads zk and reduces latency impact > we should have details of this in the forrest docs. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (ZOOKEEPER-417) stray message problem when changing servers
[
https://issues.apache.org/jira/browse/ZOOKEEPER-417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick Hunt reassigned ZOOKEEPER-417:
--
Assignee: Benjamin Reed
> stray message problem when changing servers
> ---
>
> Key: ZOOKEEPER-417
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-417
> Project: Zookeeper
> Issue Type: Bug
>Reporter: Benjamin Reed
>Assignee: Benjamin Reed
>Priority: Blocker
> Fix For: 3.2.0
>
>
> There is a possibility for stray messages from a previous connection to
> violate ordering and generally cause problems. Here is a scenario: we have a
> client, C, two followers, F1 and F2, and a leader, L. The client is connected
> to F1, which is a slow follower. C sends setData("/a", "1") to F1 and then
> loses the connection, so C reconnects to F2 and sends setData("/a", "2"). it
> is possible, if F1 is slow enough and the setData("/a", "1") got onto the
> network before the connection break, for F1 to forward the setData("/a", "1")
> to L after F2 forwards setData("/a", "2").
> to fix this, the leader should keep track of which follower last registered a
> session for a client and drop any requests from followers for clients for
> whom they do not have a registration.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (ZOOKEEPER-421) zkpython run_tests.sh is missing #!
zkpython run_tests.sh is missing #! --- Key: ZOOKEEPER-421 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-421 Project: Zookeeper Issue Type: Bug Components: contrib-bindings Reporter: Patrick Hunt Assignee: Henry Robinson Priority: Minor the scripts in the test directory of zkpython are missing #! headers Probably: #!/bin/sh for shell scripts and #!/usr/bin/python for .py scripts? Also include a shell script that will svn chmod the *.py scripts so that they can be executed individually from the command line (shortcut rather than (python foo.py). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (ZOOKEEPER-420) build/test should not require install in zkpython
build/test should not require install in zkpython - Key: ZOOKEEPER-420 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-420 Project: Zookeeper Issue Type: Bug Components: contrib-bindings Reporter: Patrick Hunt Assignee: Henry Robinson Currently you cannot just build and test the zkpython contrib, you need to actually install the zookeeper client c library as well as the zkpython lib itself. There really needs to be 2 steps: 1) build/test zkpython "encapsulated" within the src repository, there should be no requirement to actually install anything (this is esp the case for automated processes and for review by PMC during release time for example) 2) build an egg that can be distributed/installed by end user -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-419) Reference counting bug in Python bindings causes abort errors
[ https://issues.apache.org/jira/browse/ZOOKEEPER-419?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Hunt updated ZOOKEEPER-419: --- Resolution: Fixed Hadoop Flags: [Reviewed] Status: Resolved (was: Patch Available) +1, thanks Henry Committed revision 779716. > Reference counting bug in Python bindings causes abort errors > - > > Key: ZOOKEEPER-419 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-419 > Project: Zookeeper > Issue Type: Bug > Components: contrib-bindings >Reporter: Henry Robinson >Assignee: Henry Robinson >Priority: Critical > Fix For: 3.2.0 > > Attachments: ZOOKEEPER-419.patch > > > Due to reference counts being incremented incorrectly for stat-based calls, > Python's GC occasionally aborts. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-419) Reference counting bug in Python bindings causes abort errors
[ https://issues.apache.org/jira/browse/ZOOKEEPER-419?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12714070#action_12714070 ] Henry Robinson commented on ZOOKEEPER-419: -- > Is there test code currently that exercises the "stat and acl objects passed > to Py_BuildValue." codepath? Yes - there's a get-set test that will go through this code path. Every time an API call returns, it invokes Py_BuildValue to construct the python representation of the C data type. > Reference counting bug in Python bindings causes abort errors > - > > Key: ZOOKEEPER-419 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-419 > Project: Zookeeper > Issue Type: Bug > Components: contrib-bindings >Reporter: Henry Robinson >Assignee: Henry Robinson >Priority: Critical > Fix For: 3.2.0 > > Attachments: ZOOKEEPER-419.patch > > > Due to reference counts being incremented incorrectly for stat-based calls, > Python's GC occasionally aborts. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-419) Reference counting bug in Python bindings causes abort errors
[ https://issues.apache.org/jira/browse/ZOOKEEPER-419?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12714062#action_12714062 ] Henry Robinson commented on ZOOKEEPER-419: -- Thanks, those are good pointers. I need to expand the test coverage for the bindings beyond simply exercising the API. I'll set up another JIRA for that. > Reference counting bug in Python bindings causes abort errors > - > > Key: ZOOKEEPER-419 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-419 > Project: Zookeeper > Issue Type: Bug > Components: contrib-bindings >Reporter: Henry Robinson >Assignee: Henry Robinson >Priority: Critical > Fix For: 3.2.0 > > Attachments: ZOOKEEPER-419.patch > > > Due to reference counts being incremented incorrectly for stat-based calls, > Python's GC occasionally aborts. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-419) Reference counting bug in Python bindings causes abort errors
[ https://issues.apache.org/jira/browse/ZOOKEEPER-419?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12714056#action_12714056 ] Patrick Hunt commented on ZOOKEEPER-419: For future ref: I did a quick search and noticed the following which might be helpful at some point for testing ref cnts: 1) http://docs.python.org/library/gc.html 2) see class "TrackRefs" http://cvs.zope.org/*checkout*/Zope3/test.py?rev=1.100&content-type=text/plain > Reference counting bug in Python bindings causes abort errors > - > > Key: ZOOKEEPER-419 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-419 > Project: Zookeeper > Issue Type: Bug > Components: contrib-bindings >Reporter: Henry Robinson >Assignee: Henry Robinson >Priority: Critical > Fix For: 3.2.0 > > Attachments: ZOOKEEPER-419.patch > > > Due to reference counts being incremented incorrectly for stat-based calls, > Python's GC occasionally aborts. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-419) Reference counting bug in Python bindings causes abort errors
[ https://issues.apache.org/jira/browse/ZOOKEEPER-419?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12714049#action_12714049 ] Patrick Hunt commented on ZOOKEEPER-419: Is there test code currently that exercises the "stat and acl objects passed to Py_BuildValue." codepath? If so then I'd say this is fine, otw I'd suggest adding a test or two that exercise this codepath. Perhaps add a JIRA that documents we need to verify refcnt at some point? Is there some facility/extn/addon for python that supports test/verification of refcnt correctness? > Reference counting bug in Python bindings causes abort errors > - > > Key: ZOOKEEPER-419 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-419 > Project: Zookeeper > Issue Type: Bug > Components: contrib-bindings >Reporter: Henry Robinson >Assignee: Henry Robinson >Priority: Critical > Fix For: 3.2.0 > > Attachments: ZOOKEEPER-419.patch > > > Due to reference counts being incremented incorrectly for stat-based calls, > Python's GC occasionally aborts. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-419) Reference counting bug in Python bindings causes abort errors
[ https://issues.apache.org/jira/browse/ZOOKEEPER-419?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12713979#action_12713979 ] Henry Robinson commented on ZOOKEEPER-419: -- This is hard to test for explicitly, as GC is non-deterministic and covering all the cases is difficult. I expect these kinds of error to shake out when I expand the test suite. Hudson wouldn't pick up any new Python tests anyhow. It's a simple change without any alterations to the logic of the bindings - just correcting the parameters to a Python C API call. However, this bug is blocking progress on a project for me, and it would be helpful to have it committed asap, if committers have time and agree. > Reference counting bug in Python bindings causes abort errors > - > > Key: ZOOKEEPER-419 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-419 > Project: Zookeeper > Issue Type: Bug > Components: contrib-bindings >Reporter: Henry Robinson >Assignee: Henry Robinson >Priority: Critical > Fix For: 3.2.0 > > Attachments: ZOOKEEPER-419.patch > > > Due to reference counts being incremented incorrectly for stat-based calls, > Python's GC occasionally aborts. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-383) Asynchronous version of createLedger()
[ https://issues.apache.org/jira/browse/ZOOKEEPER-383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12713963#action_12713963 ] Hudson commented on ZOOKEEPER-383: -- Integrated in ZooKeeper-trunk #328 (See [http://hudson.zones.apache.org/hudson/job/ZooKeeper-trunk/328/]) . Asynchronous version of createLedger(). (flavio via mahadev) > Asynchronous version of createLedger() > -- > > Key: ZOOKEEPER-383 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-383 > Project: Zookeeper > Issue Type: New Feature > Components: contrib-bookkeeper >Reporter: Utkarsh Srivastava >Assignee: Flavio Paiva Junqueira > Fix For: 3.2.0 > > Attachments: ZOOKEEPER-383.patch, ZOOKEEPER-383.patch, > ZOOKEEPER-383.patch, ZOOKEEPER-383.patch, ZOOKEEPER-383.patch, > ZOOKEEPER-383.patch > > > While there are async versions for read and write, there is no async version > for creating a ledger. This can cause applications to have to change their > whole thread design. > It should be easier and more consistent to add an async version of > createLedger(). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-416) BookKeeper jar includes unnecessary files
[
https://issues.apache.org/jira/browse/ZOOKEEPER-416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12713964#action_12713964
]
Hudson commented on ZOOKEEPER-416:
--
Integrated in ZooKeeper-trunk #328 (See
[http://hudson.zones.apache.org/hudson/job/ZooKeeper-trunk/328/])
. bookkeeper jar includes unnnecessary files. (flavio via mahadev)
> BookKeeper jar includes unnecessary files
> -
>
> Key: ZOOKEEPER-416
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-416
> Project: Zookeeper
> Issue Type: Bug
> Components: contrib-bookkeeper
>Reporter: Flavio Paiva Junqueira
>Assignee: Flavio Paiva Junqueira
> Fix For: 3.2.0
>
> Attachments: ZOOKEEPER-416.patch
>
>
> I was checking the bookkeper jar, and I found that it includes some
> unnecessary files related to junit, such as:
> {noformat}
> 0 Tue May 12 19:00:14 PDT 2009 tmp/
> 0 Tue May 12 19:00:00 PDT 2009 tmp/test14667.junit.dir/
> 0 Tue May 12 19:00:08 PDT 2009 tmp/test14667.junit.dir/version-2/
> 0 Tue May 12 19:00:10 PDT 2009 tmp/test16109.junit.dir/
> 0 Tue May 12 19:00:16 PDT 2009 tmp/test16109.junit.dir/version-2/
> 0 Tue May 12 19:00:14 PDT 2009 tmp/test16113.junit.dir/
> 0 Tue May 12 19:00:16 PDT 2009 tmp/test16113.junit.dir/version-2/
> 2256 Tue May 12 18:59:08 PDT 2009
> logs/TEST-org.apache.bookkeeper.test.BookieClientTest.txt
> 167046 Tue May 12 19:00:00 PDT 2009
> logs/TEST-org.apache.bookkeeper.test.BookieReadWriteTest.txt
> 13035 Tue May 12 19:00:08 PDT 2009
> logs/TEST-org.apache.bookkeeper.test.CloseTest.txt
> 25036 Tue May 12 19:00:16 PDT 2009
> logs/TEST-org.apache.bookkeeper.test.LedgerRecoveryTest.txt
>896 Tue May 12 19:00:16 PDT 2009
> logs/TEST-org.apache.bookkeeper.test.NIOServerFactoryTest.txt
> {noformat}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
