[jira] Updated: (ZOOKEEPER-318) remove locking in zk_hashtable.c or add locking in collect_keys()
[ https://issues.apache.org/jira/browse/ZOOKEEPER-318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Darroch updated ZOOKEEPER-318: Attachment: ZOOKEEPER-318.patch Renamed patch file with issue key. remove locking in zk_hashtable.c or add locking in collect_keys() - Key: ZOOKEEPER-318 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-318 Project: Zookeeper Issue Type: Bug Components: c client Affects Versions: 3.0.0, 3.0.1, 3.1.0 Reporter: Chris Darroch Fix For: 3.2.0, 4.0.0 Attachments: ZOOKEEPER-318.patch From a review of zk_hashtable.c it appears to me that all functions which manipulate the hashtables are called from the IO thread, and therefore any need for locking is obviated. If I'm wrong about that, then I think at a minimum collect_keys() should acquire a lock in the same manner as collect_session_watchers(). Both iterate over hashtable contents (in the latter case using copy_table()). However, from what I can see, the only function (besides the init/destroy functions used when creating a zhandle_t) called from the completion thread is deliverWatchers(), which simply iterates over a delivery list created from the hashtables by collectWatchers(). The activateWatcher() function contains comments which describe it being called by the completion thread, but in fact it is called by the IO thread in zookeeper_process(). I believe all calls to collectWatchers(), activateWatcher(), and collect_keys() are made by the IO thread in zookeeper_interest(), zookeeper_process(), check_events(), send_set_watches(), and handle_error(). Note that queue_session_event() is aliased as PROCESS_SESSION_EVENT, but appears only in handle_error() and check_events(). Also note that handle_error() is called only in zookeeper_process() and handle_socket_error_msg(), which is used only by the IO thread, so far as I can see. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-318) remove locking in zk_hashtable.c or add locking in collect_keys()
[ https://issues.apache.org/jira/browse/ZOOKEEPER-318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Darroch updated ZOOKEEPER-318: Attachment: (was: zk_hashtable.patch) remove locking in zk_hashtable.c or add locking in collect_keys() - Key: ZOOKEEPER-318 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-318 Project: Zookeeper Issue Type: Bug Components: c client Affects Versions: 3.0.0, 3.0.1, 3.1.0 Reporter: Chris Darroch Fix For: 3.2.0, 4.0.0 Attachments: ZOOKEEPER-318.patch From a review of zk_hashtable.c it appears to me that all functions which manipulate the hashtables are called from the IO thread, and therefore any need for locking is obviated. If I'm wrong about that, then I think at a minimum collect_keys() should acquire a lock in the same manner as collect_session_watchers(). Both iterate over hashtable contents (in the latter case using copy_table()). However, from what I can see, the only function (besides the init/destroy functions used when creating a zhandle_t) called from the completion thread is deliverWatchers(), which simply iterates over a delivery list created from the hashtables by collectWatchers(). The activateWatcher() function contains comments which describe it being called by the completion thread, but in fact it is called by the IO thread in zookeeper_process(). I believe all calls to collectWatchers(), activateWatcher(), and collect_keys() are made by the IO thread in zookeeper_interest(), zookeeper_process(), check_events(), send_set_watches(), and handle_error(). Note that queue_session_event() is aliased as PROCESS_SESSION_EVENT, but appears only in handle_error() and check_events(). Also note that handle_error() is called only in zookeeper_process() and handle_socket_error_msg(), which is used only by the IO thread, so far as I can see. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-309) core dump using zoo_get_acl()
[ https://issues.apache.org/jira/browse/ZOOKEEPER-309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Darroch updated ZOOKEEPER-309: Attachment: ZOOKEEPER-309.patch Renamed patch file with issue key. core dump using zoo_get_acl() -- Key: ZOOKEEPER-309 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-309 Project: Zookeeper Issue Type: Bug Components: c client Affects Versions: 3.0.0, 3.0.1, 3.1.0 Reporter: Chris Darroch Fix For: 3.1.1, 3.2.0 Attachments: ZOOKEEPER-309.patch The zookeeper_process() function incorrectly calls the c.acl_result member of the completion_list_t structure when handling the completion from a synchronous zoo_get_acl() request. The c.acl_result member is set to SYNCHRONOUS_MARKER, which is a null pointer. The attached patch removes this call. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (ZOOKEEPER-323) Log file reuse
Log file reuse -- Key: ZOOKEEPER-323 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-323 Project: Zookeeper Issue Type: Improvement Components: server Reporter: Benjamin Reed in some benchmarks i noticed that you can get much higher throughput using preallocated files rather than doing the grow-by-padding approach that we use. we should recycle log files that are no longer needed. this should give us a performance boost. it will also make the purgelog utility unnecessary. we should have a policy that we only keep X snapshots and associated logs and reuse older log files (and probably delete the older snapshots as well since the snapshot would be useless without the corresponding log file.) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (ZOOKEEPER-324) do not materialize strings in the server
do not materialize strings in the server Key: ZOOKEEPER-324 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-324 Project: Zookeeper Issue Type: Improvement Components: server Reporter: Benjamin Reed We convert paths and authentication information to strings rather than byte[] even though we could work just as well with byte[] for our needs since we don't really interpret the strings. we are just doing basic pattern matching. the only really string manipulations we do with paths is to look for '/', but we could easily to that with byte[] since we use utf8 encoding for the strings. by not materializing the strings we save time doing the serializations and also space since most (almost all) of our strings are ASCII and thus just one byte. we could probably get by without even changing the jute spec if we make the generated classes check for a flag to see whether strings should be treated as byte[] or String. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (ZOOKEEPER-325) FLENewEpoch test fails.
FLENewEpoch test fails. --- Key: ZOOKEEPER-325 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-325 Project: Zookeeper Issue Type: Bug Affects Versions: 3.1.0 Environment: linux 2.6.9-5.ELsmp Reporter: Mahadev konar Fix For: 3.2.0 Attachments: TEST-org.apache.zookeeper.test.FLENewEpochTest.txt FLENewEpochTest fails quite frequently on my machine. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-308) improve the atomic broadcast performance 3x
[ https://issues.apache.org/jira/browse/ZOOKEEPER-308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mahadev konar updated ZOOKEEPER-308: Attachment: ZOOKEEPER-308.patch this patch has a minor indentation change. improve the atomic broadcast performance 3x --- Key: ZOOKEEPER-308 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-308 Project: Zookeeper Issue Type: Improvement Components: server Reporter: Benjamin Reed Assignee: Benjamin Reed Attachments: dat.png, ZOOKEEPER-308.patch, ZOOKEEPER-308.patch, ZOOKEEPER-308.patch We need a benchmark for zab, the atomic broadcast protocol of zookeeper. we can also do some small tweaks to make zab go much faster. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-78) added a high level protocol/feature - for easy Leader Election or exclusive Write Lock creation
[ https://issues.apache.org/jira/browse/ZOOKEEPER-78?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mahadev konar updated ZOOKEEPER-78: --- Attachment: ZOOKEEPER-78.patch it would be great ot have this jira in 3.2. this patch removes the zookeeper facade, and makes it work with the current trunk. I have to still go through all the corner cases and see if they have been handled. Also, I need to implement the lock interface in writelock. comments are welcome... added a high level protocol/feature - for easy Leader Election or exclusive Write Lock creation --- Key: ZOOKEEPER-78 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-78 Project: Zookeeper Issue Type: New Feature Components: java client Affects Versions: 3.0.0 Reporter: james strachan Assignee: james strachan Fix For: 3.2.0 Attachments: patch_with_including_Benjamin's_fix.patch, using_zookeeper_facade.patch, ZOOKEEPER-78.patch Here's a patch which adds a little WriteLock helper class for performing leader elections or creating exclusive locks in some directory znode. Note its an early cut; am sure we can improve it over time. The aim is to avoid folks having to use the low level ZK stuff but provide a simpler high level abstraction. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
