[jira] [Commented] (ZOOKEEPER-965) Need a multi-update command to allow multiple znodes to be updated safely
[ https://issues.apache.org/jira/browse/ZOOKEEPER-965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13045804#comment-13045804 ] Marshall McMullen commented on ZOOKEEPER-965: - Ted, the changes in 5ce6043f4 look great to me. Much simpler than how I originally coded it. Thanks very much for refactoring that mess! Yes, I think this is the final state unless Benjamin sees anything amiss in my most recent commit to refactor the large multi-op case statement into a couple of functions. Otherwise I think we've finally finished this massive beast. Need a multi-update command to allow multiple znodes to be updated safely - Key: ZOOKEEPER-965 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-965 Project: ZooKeeper Issue Type: Bug Affects Versions: 3.3.3 Reporter: Ted Dunning Assignee: Ted Dunning Fix For: 3.4.0 Attachments: ZOOKEEPER-965.patch, ZOOKEEPER-965.patch, ZOOKEEPER-965.patch, ZOOKEEPER-965.patch, ZOOKEEPER-965.patch, ZOOKEEPER-965.patch, ZOOKEEPER-965.patch, ZOOKEEPER-965.patch, ZOOKEEPER-965.patch, ZOOKEEPER-965.patch, ZOOKEEPER-965.patch, ZOOKEEPER-965.patch, ZOOKEEPER-965.patch, ZOOKEEPER-965.patch, ZOOKEEPER-965.patch, ZOOKEEPER-965.patch, ZOOKEEPER-965.patch, ZOOKEEPER-965.patch, ZOOKEEPER-965.patch The basic idea is to have a single method called multi that will accept a list of create, delete, update or check objects each of which has a desired version or file state in the case of create. If all of the version and existence constraints can be satisfied, then all updates will be done atomically. Two API styles have been suggested. One has a list as above and the other style has a Transaction that allows builder-like methods to build a set of updates and a commit method to finalize the transaction. This can trivially be reduced to the first kind of API so the list based API style should be considered the primitive and the builder style should be implemented as syntactic sugar. The total size of all the data in all updates and creates in a single transaction should be limited to 1MB. Implementation-wise this capability can be done using standard ZK internals. The changes include: - update to ZK clients to all the new call - additional wire level request - on the server, in the code that converts transactions to idempotent form, the code should be slightly extended to convert a list of operations to idempotent form. - on the client, a down-rev server that rejects the multi-update should be detected gracefully and an informative exception should be thrown. To facilitate shared development, I have established a github repository at https://github.com/tdunning/zookeeper and am happy to extend committer status to anyone who agrees to donate their code back to Apache. The final patch will be attached to this bug as normal. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
Samle program for making any service highly available using zookeeper
Hi , We used zookeeper to make one of our service highly available. I have written a sample program which shows the usage of zookeeper to make the required service highly available . Can it be added it to examples package in the zookeeper code ? Thanks Regards, Divya
[jira] [Commented] (ZOOKEEPER-965) Need a multi-update command to allow multiple znodes to be updated safely
[ https://issues.apache.org/jira/browse/ZOOKEEPER-965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13045972#comment-13045972 ] Marshall McMullen commented on ZOOKEEPER-965: - Ted, can you post an updated patch? Need a multi-update command to allow multiple znodes to be updated safely - Key: ZOOKEEPER-965 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-965 Project: ZooKeeper Issue Type: Bug Affects Versions: 3.3.3 Reporter: Ted Dunning Assignee: Ted Dunning Fix For: 3.4.0 Attachments: ZOOKEEPER-965.patch, ZOOKEEPER-965.patch, ZOOKEEPER-965.patch, ZOOKEEPER-965.patch, ZOOKEEPER-965.patch, ZOOKEEPER-965.patch, ZOOKEEPER-965.patch, ZOOKEEPER-965.patch, ZOOKEEPER-965.patch, ZOOKEEPER-965.patch, ZOOKEEPER-965.patch, ZOOKEEPER-965.patch, ZOOKEEPER-965.patch, ZOOKEEPER-965.patch, ZOOKEEPER-965.patch, ZOOKEEPER-965.patch, ZOOKEEPER-965.patch, ZOOKEEPER-965.patch, ZOOKEEPER-965.patch The basic idea is to have a single method called multi that will accept a list of create, delete, update or check objects each of which has a desired version or file state in the case of create. If all of the version and existence constraints can be satisfied, then all updates will be done atomically. Two API styles have been suggested. One has a list as above and the other style has a Transaction that allows builder-like methods to build a set of updates and a commit method to finalize the transaction. This can trivially be reduced to the first kind of API so the list based API style should be considered the primitive and the builder style should be implemented as syntactic sugar. The total size of all the data in all updates and creates in a single transaction should be limited to 1MB. Implementation-wise this capability can be done using standard ZK internals. The changes include: - update to ZK clients to all the new call - additional wire level request - on the server, in the code that converts transactions to idempotent form, the code should be slightly extended to convert a list of operations to idempotent form. - on the client, a down-rev server that rejects the multi-update should be detected gracefully and an informative exception should be thrown. To facilitate shared development, I have established a github repository at https://github.com/tdunning/zookeeper and am happy to extend committer status to anyone who agrees to donate their code back to Apache. The final patch will be attached to this bug as normal. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (ZOOKEEPER-1079) 'Create' command in Hbase makes a table in Hbase but it sends 'Delete' request to Zookeeper !!!
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1079?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Hunt resolved ZOOKEEPER-1079. - Resolution: Not A Problem Closing as Mohamad says this is not a bug. Thanks for the report! 'Create' command in Hbase makes a table in Hbase but it sends 'Delete' request to Zookeeper !!! --- Key: ZOOKEEPER-1079 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1079 Project: ZooKeeper Issue Type: Test Affects Versions: 3.3.3 Reporter: Mohamad Koohi-Moghadam when use 'Create' in Hbase== Got user-level KeeperException... type:delete And caused zookeper make Nonode Exception and when make a znode in zookeeper shell for example a node with name 'mkm' , and in hbase command line use create 'mkm' , 'm' this command delete 'mkm' from zookeeper !! Linux Ubuntu Zookeeper and Hbase -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Samle program for making any service highly available using zookeeper
IMO one area in which we are particularly weak is good client side user examples, so yes, please do submit! If you could add sufficient supporting comments/javadoc/docs along with the example I think it would be particularly helpful to end users. Regards, Patrick On Wed, Jun 8, 2011 at 1:56 AM, Divya :P divyaprabha...@gmail.com wrote: Hi , We used zookeeper to make one of our service highly available. I have written a sample program which shows the usage of zookeeper to make the required service highly available . Can it be added it to examples package in the zookeeper code ? Thanks Regards, Divya
[jira] [Created] (ZOOKEEPER-1088) delQuota does not remove the quota node and subesquent setquota calls for that path will fail
delQuota does not remove the quota node and subesquent setquota calls for that path will fail - Key: ZOOKEEPER-1088 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1088 Project: ZooKeeper Issue Type: Bug Components: server Affects Versions: 3.3.3 Reporter: Camille Fournier Assignee: Camille Fournier Fix For: 3.3.4, 3.4.0 sequota -b 1000 /testing delquota -b /testing setquota -n 1024 /testing Command failed: java.lang.IllegalArgumentException: /testing has a parent /zookeeper/quota/testing which has a quota -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
Released versions in jira
Looks like our jira thinks we haven't released 3.3.3. Anyone know how to fix this? C
Re: Released versions in jira
ah dang. i'm sure that is my fault. we need to add that to the release process wiki. do you know how to do this pat? ben On Wed, Jun 8, 2011 at 1:06 PM, Camille Fournier skami...@gmail.com wrote: Looks like our jira thinks we haven't released 3.3.3. Anyone know how to fix this? C
[jira] [Commented] (ZOOKEEPER-1088) delQuota does not remove the quota node and subesquent setquota calls for that path will fail
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1088?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13046217#comment-13046217 ] Camille Fournier commented on ZOOKEEPER-1088: - Ah this appears to be just a really poorly-documented feature. If no flag is passed, it will completely delete the node. If both flags are passed, it will swallow the command. Deciding whether to clean that up or just close this. delQuota does not remove the quota node and subesquent setquota calls for that path will fail - Key: ZOOKEEPER-1088 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1088 Project: ZooKeeper Issue Type: Bug Components: server Affects Versions: 3.3.3 Reporter: Camille Fournier Assignee: Camille Fournier Fix For: 3.3.4, 3.4.0 Original Estimate: 24h Remaining Estimate: 24h sequota -b 1000 /testing delquota -b /testing setquota -n 1024 /testing Command failed: java.lang.IllegalArgumentException: /testing has a parent /zookeeper/quota/testing which has a quota -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (ZOOKEEPER-1080) Provide a Leader Election framework based on Zookeeper receipe
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1080?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13046221#comment-13046221 ] E. Sammer commented on ZOOKEEPER-1080: -- I've written a simple library that does exactly this for another project that uses ZK. I haven't read the attached design document attached, but I'm happy to contribute the code anyway, if it's useful. I'll upload it later today for others to review. Provide a Leader Election framework based on Zookeeper receipe -- Key: ZOOKEEPER-1080 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1080 Project: ZooKeeper Issue Type: New Feature Components: contrib Affects Versions: 3.3.2 Reporter: Hari A V Attachments: LeaderElectionService.pdf Currently Hadoop components such as NameNode and JobTracker are single point of failure. If Namenode or JobTracker goes down, there service will not be available until they are up and running again. If there was a Standby Namenode or JobTracker available and ready to serve when Active nodes go down, we could have reduced the service down time. Hadoop already provides a Standby Namenode implementation which is not fully a hot Standby. The common problem to be addressed in any such Active-Standby cluster is Leader Election and Failure detection. This can be done using Zookeeper as mentioned in the Zookeeper recipes. http://zookeeper.apache.org/doc/r3.3.3/recipes.html +Leader Election Service (LES)+ Any Node who wants to participate in Leader Election can use this service. They should start the service with required configurations. The service will notify the nodes whether they should be started as Active or Standby mode. Also they intimate any changes in the mode at runtime. All other complexities can be handled internally by the LES. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Released versions in jira
https://issues.apache.org/jira/browse/ZOOKEEPER Click on versions on the left, then click on manage versions on the right. Then click on release and give it the correct date of the release. Can you do all that, or do you need to be admin? Patrick On Wed, Jun 8, 2011 at 1:54 PM, Benjamin Reed br...@apache.org wrote: ah dang. i'm sure that is my fault. we need to add that to the release process wiki. do you know how to do this pat? ben On Wed, Jun 8, 2011 at 1:06 PM, Camille Fournier skami...@gmail.com wrote: Looks like our jira thinks we haven't released 3.3.3. Anyone know how to fix this? C
