Feature: Allow ephemeral nodes to have children
Hello, I was just re-reading part of the ZooKeeper documentation and I was trying to understand why ephemeral znodes should not have children znodes. Adding this feature, while maintaining an important restriction, could be really useful. Let's suppose that we have a multi-agent system and we are using ZooKeeper to store status for each agent. Most of the time the agent status can be expressed as a bunch of (key, value) pairs and, because we can't create children for ephemeral znodes, we need to serialize this data structure as a byte string. By doing this we make the status information hard to retrieve and also a bit difficult (and inefficient) to update. I believe that it's a good idea to allow the ephemeralOwner session to create children znodes. By doing this we eliminate the need to serialize status information. We should end-up having a tree structure looking like this: /agent-000234 /active -- is active now /memory -- memory usage for this agent /ip -- the IP address of the system where the agent is running /port-- the port where the agent is listening for commands ... etc. This is somehow similar to /proc on Unix systems. It shouldn't be that difficult to cleanup this if the session expires or is closed. In the near future I would like to use this feature at http://indekspot.com to publish Apache Solr status information in order to be able to easily monitor and manage the running servers. What do you think? Do you find this feature useful? Thanks -- Andrei Savu -- http://andreisavu.ro
Build failed in Hudson: ZooKeeper-trunk #897
See http://hudson.zones.apache.org/hudson/job/ZooKeeper-trunk/897/ -- Started by timer Building remotely on hadoop8 (Ubuntu) Updating http://svn.apache.org/repos/asf/hadoop/zookeeper/trunk ERROR: Failed to update http://svn.apache.org/repos/asf/hadoop/zookeeper/trunk org.tmatesoft.svn.core.SVNException: svn: unknown host svn: OPTIONS request failed on '/repos/asf/hadoop/zookeeper/trunk' at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:103) at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:87) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:616) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:273) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:261) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(DAVConnection.java:516) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.java:98) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.openConnection(DAVRepository.java:1001) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getRepositoryUUID(DAVRepository.java:146) at org.tmatesoft.svn.core.wc.SVNBasicClient.createRepository(SVNBasicClient.java:342) at org.tmatesoft.svn.core.wc.SVNBasicClient.createRepository(SVNBasicClient.java:330) at org.tmatesoft.svn.core.wc.SVNUpdateClient.update(SVNUpdateClient.java:535) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:401) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:699) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:660) at hudson.FilePath$FileCallableWrapper.call(FilePath.java:1899) at hudson.remoting.UserRequest.perform(UserRequest.java:114) at hudson.remoting.UserRequest.perform(UserRequest.java:48) at hudson.remoting.Request$2.run(Request.java:270) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:619) Caused by: java.net.UnknownHostException: svn.apache.org at java.net.Inet6AddressImpl.lookupAllHostAddr(Native Method) at java.net.InetAddress$1.lookupAllHostAddr(InetAddress.java:849) at java.net.InetAddress.getAddressFromNameService(InetAddress.java:1200) at java.net.InetAddress.getAllByName0(InetAddress.java:1153) at java.net.InetAddress.getAllByName(InetAddress.java:1083) at java.net.InetAddress.getAllByName(InetAddress.java:1019) at java.net.InetAddress.getByName(InetAddress.java:969) at org.tmatesoft.svn.core.internal.util.SVNSocketFactory.createAddres(SVNSocketFactory.java:132) at org.tmatesoft.svn.core.internal.util.SVNSocketFactory.createPlainSocket(SVNSocketFactory.java:54) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.connect(HTTPConnection.java:183) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:323) ... 22 more [WARNINGS] Skipping publisher since build result is FAILURE [FINDBUGS] Skipping publisher since build result is FAILURE Publishing Javadoc Recording fingerprints Archiving artifacts Recording test results Publishing Clover coverage report... Publishing Clover HTML report... Publishing Clover XML report... Publishing Clover coverage results...
Re: Feature: Allow ephemeral nodes to have children
Hey Andrei, I was just re-reading part of the ZooKeeper documentation and I was trying to understand why ephemeral znodes should not have children znodes. Adding this feature, while maintaining an important restriction, could be really useful. Indeed. There was some discussion about this idea in this mailing list a few months ago, and the conclusion IIRC is that it is indeed an interesting feature, and there's an approach which is apparently feasible too without too much trouble, but no one is taking care of the idea right now. It'd be good to find someone that is interested in trying it out (hint hint). -- Gustavo Niemeyer http://niemeyer.net http://niemeyer.net/blog http://niemeyer.net/twitter
[jira] Updated: (ZOOKEEPER-809) Improved REST Interface
[
https://issues.apache.org/jira/browse/ZOOKEEPER-809?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrei Savu updated ZOOKEEPER-809:
--
Attachment: ZOOKEEPER-809.patch
In this patch:
* ant task for packaging: just run {{ant tar}} and it will generate
{{zookeeper-dev-rest.tar.gz}} in {{build/contrib/rest/}}
* basic script for starting and stopping the REST gateway -
{{bin/restServer.sh}}
Remaining:
* ACLs ZooKeeper Authentication - after GSoC soft deadline
All tests are passing, including the ones from the new python client test suite.
Improved REST Interface
---
Key: ZOOKEEPER-809
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-809
Project: Zookeeper
Issue Type: Improvement
Components: contrib
Reporter: Andrei Savu
Assignee: Andrei Savu
Attachments: SPEC.txt, SPEC.txt, ZOOKEEPER-809.patch,
ZOOKEEPER-809.patch, ZOOKEEPER-809.patch
I would like to extend the existing REST Interface to also support:
* configuration
* ephemeral znodes
* watches - PubSubHubbub
* ACLs
* basic authentication
I want to do this because when building web applications that talks directly
to ZooKeeper a REST API it's a lot easier to use (there is no protocol
mismatch) than an API that uses persistent connections. I plan to use the
improved version to build a web-based administrative interface.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-822) Leader election taking a long time to complete
[ https://issues.apache.org/jira/browse/ZOOKEEPER-822?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12896043#action_12896043 ] Ivan Kelly commented on ZOOKEEPER-822: -- I've tried to repro this with 3 zookeepers running on the same machine, and 3 zookeepers running on virtual machine and I cannot get it to repro. I was taking out the leader by shutting down the network interface. Have you been able to repro this on another set of machines other than the ones you first observed it on? Also, could you try this with the latest trunk? Some improvements were made around the FLE which may shed some more light. Leader election taking a long time to complete --- Key: ZOOKEEPER-822 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-822 Project: Zookeeper Issue Type: Bug Components: quorum Affects Versions: 3.3.0 Reporter: Vishal K Priority: Blocker Attachments: 822.tar.gz, test_zookeeper_1.log, test_zookeeper_2.log, zk_leader_election.tar.gz Created a 3 node cluster. 1 Fail the ZK leader 2. Let leader election finish. Restart the leader and let it join the 3. Repeat After a few rounds leader election takes anywhere 25- 60 seconds to finish. Note- we didn't have any ZK clients and no new znodes were created. zoo.cfg is shown below: #Mon Jul 19 12:15:10 UTC 2010 server.1=192.168.4.12\:2888\:3888 server.0=192.168.4.11\:2888\:3888 clientPort=2181 dataDir=/var/zookeeper syncLimit=2 server.2=192.168.4.13\:2888\:3888 initLimit=5 tickTime=2000 I have attached logs from two nodes that took a long time to form the cluster after failing the leader. The leader was down anyways so logs from that node shouldn't matter. Look for START HERE. Logs after that point should be of our interest. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-822) Leader election taking a long time to complete
[ https://issues.apache.org/jira/browse/ZOOKEEPER-822?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12896061#action_12896061 ] Vishal K commented on ZOOKEEPER-822: Hi Ivan. Were the logs of any help? I might be worth having 3 VMs and rebooting the leader instead of shutting down the interface. We have seen this on all of our dev cluster. Al tough all the dev clusters are based on same VM images. So it won't be fair to claim that the problem was seen on different set of machines. I will try with the latest trunk and let you know the result. What FLE changes do you think would have fixed this problem? Thanks. -Vishal Leader election taking a long time to complete --- Key: ZOOKEEPER-822 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-822 Project: Zookeeper Issue Type: Bug Components: quorum Affects Versions: 3.3.0 Reporter: Vishal K Priority: Blocker Attachments: 822.tar.gz, test_zookeeper_1.log, test_zookeeper_2.log, zk_leader_election.tar.gz Created a 3 node cluster. 1 Fail the ZK leader 2. Let leader election finish. Restart the leader and let it join the 3. Repeat After a few rounds leader election takes anywhere 25- 60 seconds to finish. Note- we didn't have any ZK clients and no new znodes were created. zoo.cfg is shown below: #Mon Jul 19 12:15:10 UTC 2010 server.1=192.168.4.12\:2888\:3888 server.0=192.168.4.11\:2888\:3888 clientPort=2181 dataDir=/var/zookeeper syncLimit=2 server.2=192.168.4.13\:2888\:3888 initLimit=5 tickTime=2000 I have attached logs from two nodes that took a long time to form the cluster after failing the leader. The leader was down anyways so logs from that node shouldn't matter. Look for START HERE. Logs after that point should be of our interest. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-822) Leader election taking a long time to complete
[ https://issues.apache.org/jira/browse/ZOOKEEPER-822?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12896063#action_12896063 ] Ivan Kelly commented on ZOOKEEPER-822: -- They logs were of some help, but I don't understand what's happening. I looks like multiple nodes are claiming leadership at the same time, but that can't be right. The FLE changes won't fix it, but they do log more information, so they may make it easier to see what is happening. Leader election taking a long time to complete --- Key: ZOOKEEPER-822 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-822 Project: Zookeeper Issue Type: Bug Components: quorum Affects Versions: 3.3.0 Reporter: Vishal K Priority: Blocker Attachments: 822.tar.gz, test_zookeeper_1.log, test_zookeeper_2.log, zk_leader_election.tar.gz Created a 3 node cluster. 1 Fail the ZK leader 2. Let leader election finish. Restart the leader and let it join the 3. Repeat After a few rounds leader election takes anywhere 25- 60 seconds to finish. Note- we didn't have any ZK clients and no new znodes were created. zoo.cfg is shown below: #Mon Jul 19 12:15:10 UTC 2010 server.1=192.168.4.12\:2888\:3888 server.0=192.168.4.11\:2888\:3888 clientPort=2181 dataDir=/var/zookeeper syncLimit=2 server.2=192.168.4.13\:2888\:3888 initLimit=5 tickTime=2000 I have attached logs from two nodes that took a long time to form the cluster after failing the leader. The leader was down anyways so logs from that node shouldn't matter. Look for START HERE. Logs after that point should be of our interest. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-767) Submitting Demo/Recipe Shared / Exclusive Lock Code
[ https://issues.apache.org/jira/browse/ZOOKEEPER-767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sam Baskinger updated ZOOKEEPER-767: Attachment: ZOOKEEPER-767.patch Patch containing java and c implementations of recipe locking code. Submitting Demo/Recipe Shared / Exclusive Lock Code --- Key: ZOOKEEPER-767 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-767 Project: Zookeeper Issue Type: Improvement Components: recipes Affects Versions: 3.3.0 Reporter: Sam Baskinger Assignee: Sam Baskinger Priority: Minor Fix For: 3.4.0 Attachments: ZOOKEEPER-767.patch, ZOOKEEPER-767.patch, ZOOKEEPER-767.patch, ZOOKEEPER-767.patch Time Spent: 8h Networked Insights would like to share-back some code for shared/exclusive locking that we are using in our labs. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-767) Submitting Demo/Recipe Shared / Exclusive Lock Code
[ https://issues.apache.org/jira/browse/ZOOKEEPER-767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sam Baskinger updated ZOOKEEPER-767: Status: Open (was: Patch Available) Canceling last patch. Submitting Demo/Recipe Shared / Exclusive Lock Code --- Key: ZOOKEEPER-767 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-767 Project: Zookeeper Issue Type: Improvement Components: recipes Affects Versions: 3.3.0 Reporter: Sam Baskinger Assignee: Sam Baskinger Priority: Minor Fix For: 3.4.0 Attachments: ZOOKEEPER-767.patch, ZOOKEEPER-767.patch, ZOOKEEPER-767.patch, ZOOKEEPER-767.patch Time Spent: 8h Networked Insights would like to share-back some code for shared/exclusive locking that we are using in our labs. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-767) Submitting Demo/Recipe Shared / Exclusive Lock Code
[ https://issues.apache.org/jira/browse/ZOOKEEPER-767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sam Baskinger updated ZOOKEEPER-767: Status: Patch Available (was: Open) New patch contains java and c recipe code. Submitting Demo/Recipe Shared / Exclusive Lock Code --- Key: ZOOKEEPER-767 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-767 Project: Zookeeper Issue Type: Improvement Components: recipes Affects Versions: 3.3.0 Reporter: Sam Baskinger Assignee: Sam Baskinger Priority: Minor Fix For: 3.4.0 Attachments: ZOOKEEPER-767.patch, ZOOKEEPER-767.patch, ZOOKEEPER-767.patch, ZOOKEEPER-767.patch Time Spent: 8h Networked Insights would like to share-back some code for shared/exclusive locking that we are using in our labs. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Feature: Allow ephemeral nodes to have children
Take a look at the following. Would be a great feature to add. (search the mail archives for a full discussion, we should rehash that on the jira, or at least link the jira to that thread - would appreciate if someone could add a comment to the jira with that.) https://issues.apache.org/jira/browse/ZOOKEEPER-723 On 08/06/2010 06:39 AM, Gustavo Niemeyer wrote: Hey Andrei, I was just re-reading part of the ZooKeeper documentation and I was trying to understand why ephemeral znodes should not have children znodes. Adding this feature, while maintaining an important restriction, could be really useful. Indeed. There was some discussion about this idea in this mailing list a few months ago, and the conclusion IIRC is that it is indeed an interesting feature, and there's an approach which is apparently feasible too without too much trouble, but no one is taking care of the idea right now. It'd be good to find someone that is interested in trying it out (hint hint).
[jira] Commented: (ZOOKEEPER-800) zoo_add_auth returns ZOK if zookeeper handle is in ZOO_CLOSED_STATE
[ https://issues.apache.org/jira/browse/ZOOKEEPER-800?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12896090#action_12896090 ] Michi Mutsuzaki commented on ZOOKEEPER-800: --- Talked with Mahadev. I'm taking this bug (but don't know how to change assignee in Jira). --Michi zoo_add_auth returns ZOK if zookeeper handle is in ZOO_CLOSED_STATE --- Key: ZOOKEEPER-800 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-800 Project: Zookeeper Issue Type: Bug Components: c client Affects Versions: 3.3.1 Reporter: Michi Mutsuzaki Assignee: Mahadev konar Priority: Minor Fix For: 3.3.2, 3.4.0 This happened when I called zoo_add_auth() immediately after zookeeper_init(). It took me a while to figure out that authentication actually failed since zoo_add_auth() returned ZOK. It should return ZINVALIDSTATE instead. --Michi -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-780) zkCli.sh generates a ArrayIndexOutOfBoundsException
[ https://issues.apache.org/jira/browse/ZOOKEEPER-780?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12896118#action_12896118 ] Andrei Savu commented on ZOOKEEPER-780: --- I will take a look tomorrow. Maybe the test failure is somehow related to my change even if I don't understand how. zkCli.sh generates a ArrayIndexOutOfBoundsException - Key: ZOOKEEPER-780 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-780 Project: Zookeeper Issue Type: Bug Components: scripts Affects Versions: 3.3.1 Environment: Linux Ubuntu running in VMPlayer on top of Windows XP Reporter: Miguel Correia Assignee: Andrei Savu Priority: Minor Fix For: 3.4.0 Attachments: ZOOKEEPER-780.patch, ZOOKEEPER-780.patch, ZOOKEEPER-780.patch I'm starting to play with Zookeeper so I'm still running it in standalone mode. This is not a big issue, but here it goes for the records. I've run zkCli.sh to run some commands in the server. I created a znode /groups. When I tried to create a znode client_1 inside /groups, I forgot to include the data: an exception was generated and zkCli-sh crashed, instead of just showing an error. I tried a few variations and it seems like the problem is not including the data. A copy of the screen: [zk: localhost:2181(CONNECTED) 3] create /groups firstgroup Created /groups [zk: localhost:2181(CONNECTED) 4] create -e /groups/client_1 Exception in thread main java.lang.ArrayIndexOutOfBoundsException: 3 at org.apache.zookeeper.ZooKeeperMain.processZKCmd(ZooKeeperMain.java:678) at org.apache.zookeeper.ZooKeeperMain.processCmd(ZooKeeperMain.java:581) at org.apache.zookeeper.ZooKeeperMain.executeLine(ZooKeeperMain.java:353) at org.apache.zookeeper.ZooKeeperMain.run(ZooKeeperMain.java:311) at org.apache.zookeeper.ZooKeeperMain.main(ZooKeeperMain.java:270) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-723) ephemeral parent znodes
[ https://issues.apache.org/jira/browse/ZOOKEEPER-723?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12896128#action_12896128 ] Andrei Savu commented on ZOOKEEPER-723: --- You can find the whole discussion that generated this JIRA at the following URL: http://www.mail-archive.com/zookeeper-dev@hadoop.apache.org/msg08165.html ephemeral parent znodes --- Key: ZOOKEEPER-723 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-723 Project: Zookeeper Issue Type: New Feature Reporter: Benjamin Reed ephemeral znodes have the nice property of automatically cleaning up after themselves when the creator goes away, but since they can't have children it is hard to build subtrees that will cleanup after the clients that are using them are gone. rather than changing the semantics of ephemeral nodes, i propose ephemeral parents: znodes that disappear when they have no more children. this cleanup would happen automatically when the last child is removed. an ephemeral parent is not tied to any particular session, so even if the creator goes away, the ephemeral parent will remain as long as there are children. the when an ephemeral parent is created it will have an initial child, so that it doesn't get immediately removed. i think this child should be an ephemeral znode with a predefined name, firstChild. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (ZOOKEEPER-833) Attachments in the wiki do not work (so no presentations)
Attachments in the wiki do not work (so no presentations) - Key: ZOOKEEPER-833 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-833 Project: Zookeeper Issue Type: Bug Components: documentation Reporter: Bruce Mitchener This is apparently a known issue: http://mail-archives.apache.org/mod_mbox/hadoop-zookeeper-user/201005.mbox/%3c562709e0-0516-481f-87ad-2039a564e...@yahoo-inc.com%3e None of the attachments on the Presentations page in the wiki work (nor does the link to the screenshot on the performance page). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-767) Submitting Demo/Recipe Shared / Exclusive Lock Code
[ https://issues.apache.org/jira/browse/ZOOKEEPER-767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sam Baskinger updated ZOOKEEPER-767: Attachment: ZOOKEEPER-767.patch Patch for java and c implementations of locking in zookeeper. Submitting Demo/Recipe Shared / Exclusive Lock Code --- Key: ZOOKEEPER-767 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-767 Project: Zookeeper Issue Type: Improvement Components: recipes Affects Versions: 3.3.0 Reporter: Sam Baskinger Assignee: Sam Baskinger Priority: Minor Fix For: 3.4.0 Attachments: ZOOKEEPER-767.patch, ZOOKEEPER-767.patch, ZOOKEEPER-767.patch, ZOOKEEPER-767.patch Time Spent: 8h Networked Insights would like to share-back some code for shared/exclusive locking that we are using in our labs. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-767) Submitting Demo/Recipe Shared / Exclusive Lock Code
[ https://issues.apache.org/jira/browse/ZOOKEEPER-767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sam Baskinger updated ZOOKEEPER-767: Attachment: (was: ZOOKEEPER-767.patch) Submitting Demo/Recipe Shared / Exclusive Lock Code --- Key: ZOOKEEPER-767 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-767 Project: Zookeeper Issue Type: Improvement Components: recipes Affects Versions: 3.3.0 Reporter: Sam Baskinger Assignee: Sam Baskinger Priority: Minor Fix For: 3.4.0 Attachments: ZOOKEEPER-767.patch, ZOOKEEPER-767.patch, ZOOKEEPER-767.patch, ZOOKEEPER-767.patch Time Spent: 8h Networked Insights would like to share-back some code for shared/exclusive locking that we are using in our labs. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (ZOOKEEPER-834) Allow ephemeral znodes to have children created only by the owner session.
Allow ephemeral znodes to have children created only by the owner session. --- Key: ZOOKEEPER-834 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-834 Project: Zookeeper Issue Type: New Feature Components: c client, java client, server Reporter: Andrei Savu Fix For: 3.4.0 Ephemeral znodes are automatically removed when the client session is closed or expires and this behavior makes them very useful when you want to publish status information from active / connected clients. But there is a catch. Right now ephemerals can't have children znodes and because of that clients need to serialize status information as byte strings. This serialization renders that information almost invisible to generic zookeeper clients and hard / inefficient to update. Most of the time the status information can be expressed as a bunch of (key, value) pairs and we could easily store that using child znodes. Any ZooKeeper client can read that info without the need to reverse the serialization process and we can also easily update it. I suggest that the server should allow the ephemeral znodes to have children znodes. Each child should also be an ephemeral znode owned by the same session - parent ephemeralOwner session. Mail Archive: http://www.mail-archive.com/zookeeper-dev@hadoop.apache.org/msg09819.html Another discussion about the same topic: http://www.mail-archive.com/zookeeper-dev@hadoop.apache.org/msg08165.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Feature: Allow ephemeral nodes to have children
I've added a link to the email thread to ZOOKEEPER-723 [1]. I've also created a new JIRA for the approach I've suggested ZOOKEEPER-834 [2] I will try to provide a patch after I finish my GSoC assignment. For me it seems like a good idea to allow a session to create / own an ephemeral tree and not just leafs under persistent znodes. [1] https://issues.apache.org/jira/browse/ZOOKEEPER-723 [2] https://issues.apache.org/jira/browse/ZOOKEEPER-834 On Fri, Aug 6, 2010 at 7:21 PM, Patrick Hunt ph...@apache.org wrote: Take a look at the following. Would be a great feature to add. (search the mail archives for a full discussion, we should rehash that on the jira, or at least link the jira to that thread - would appreciate if someone could add a comment to the jira with that.) https://issues.apache.org/jira/browse/ZOOKEEPER-723 On 08/06/2010 06:39 AM, Gustavo Niemeyer wrote: Hey Andrei, I was just re-reading part of the ZooKeeper documentation and I was trying to understand why ephemeral znodes should not have children znodes. Adding this feature, while maintaining an important restriction, could be really useful. Indeed. There was some discussion about this idea in this mailing list a few months ago, and the conclusion IIRC is that it is indeed an interesting feature, and there's an approach which is apparently feasible too without too much trouble, but no one is taking care of the idea right now. It'd be good to find someone that is interested in trying it out (hint hint). -- Indekspot -- http://www.indekspot.com -- Managed Hosting for Apache Solr
Compiling c client
Hi, I'm trying to compile c client, and I'm getting error saying that jute files are missing. I've run ant compile_jute, but it didn't generate any files. Am I missing any steps? $ ant compile_jute Buildfile: build.xml init: jute: compile_jute_uptodate: compile_jute: BUILD SUCCESSFUL Total time: 0 seconds $ cd src/c $ autoreconf -if $ ./configure ... configure: error: jute files are missing! Please run ant compile_jute while in the zookeeper top level directory. Thanks! --Michi
