[jira] Updated: (ZOOKEEPER-279) Variable expansion in zoo.cfg
[
https://issues.apache.org/jira/browse/ZOOKEEPER-279?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick Hunt updated ZOOKEEPER-279:
---
Fix Version/s: 3.2.0
3.1.1
Variable expansion in zoo.cfg
-
Key: ZOOKEEPER-279
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-279
Project: Zookeeper
Issue Type: Improvement
Affects Versions: 3.1.0
Reporter: Nitay Joffe
Priority: Minor
Fix For: 3.1.1, 3.2.0
Attachments: HBaseQPC.java, zookeeper-279.patch
We would like to define certain parts of ZooKeeper's configuration using
variables that get substituted. For example, we want the ZooKeeper quorum to
be able to use a dataDir configured per user. In other words, something like:
tickTime=2000
dataDir=/tmp/zookeeper-${user.name}
clientPort=2181
initLimit=5
syncLimit=2
server.1=zoo1:2888:3888
server.2=zoo2:2888:3888
server.3=zoo3:2888:3888
I think Java already has a system for configuration that allows something
like this using Properties?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-279) Variable expansion in zoo.cfg
[
https://issues.apache.org/jira/browse/ZOOKEEPER-279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12679356#action_12679356
]
Jean-Daniel Cryans commented on ZOOKEEPER-279:
--
Thanks a lot Patrick. We'll have other patches coming in in the following weeks
so stay tunned ;)
Variable expansion in zoo.cfg
-
Key: ZOOKEEPER-279
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-279
Project: Zookeeper
Issue Type: Improvement
Affects Versions: 3.1.0
Reporter: Nitay Joffe
Priority: Minor
Fix For: 3.1.1, 3.2.0
Attachments: HBaseQPC.java, zookeeper-279.patch
We would like to define certain parts of ZooKeeper's configuration using
variables that get substituted. For example, we want the ZooKeeper quorum to
be able to use a dataDir configured per user. In other words, something like:
tickTime=2000
dataDir=/tmp/zookeeper-${user.name}
clientPort=2181
initLimit=5
syncLimit=2
server.1=zoo1:2888:3888
server.2=zoo2:2888:3888
server.3=zoo3:2888:3888
I think Java already has a system for configuration that allows something
like this using Properties?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (ZOOKEEPER-279) Variable expansion in zoo.cfg
[
https://issues.apache.org/jira/browse/ZOOKEEPER-279?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick Hunt reassigned ZOOKEEPER-279:
--
Assignee: Jean-Daniel Cryans
Variable expansion in zoo.cfg
-
Key: ZOOKEEPER-279
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-279
Project: Zookeeper
Issue Type: Improvement
Affects Versions: 3.1.0
Reporter: Nitay Joffe
Assignee: Jean-Daniel Cryans
Priority: Minor
Fix For: 3.1.1, 3.2.0
Attachments: HBaseQPC.java, zookeeper-279.patch
We would like to define certain parts of ZooKeeper's configuration using
variables that get substituted. For example, we want the ZooKeeper quorum to
be able to use a dataDir configured per user. In other words, something like:
tickTime=2000
dataDir=/tmp/zookeeper-${user.name}
clientPort=2181
initLimit=5
syncLimit=2
server.1=zoo1:2888:3888
server.2=zoo2:2888:3888
server.3=zoo3:2888:3888
I think Java already has a system for configuration that allows something
like this using Properties?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-279) Variable expansion in zoo.cfg
[
https://issues.apache.org/jira/browse/ZOOKEEPER-279?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick Hunt updated ZOOKEEPER-279:
---
Attachment: zookeeper-279.patch
Updated the patch to successfully apply against the latest codebase.
+1 - will be committed for 3.1.1/3.2 releases.
Variable expansion in zoo.cfg
-
Key: ZOOKEEPER-279
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-279
Project: Zookeeper
Issue Type: Improvement
Affects Versions: 3.1.0
Reporter: Nitay Joffe
Assignee: Jean-Daniel Cryans
Priority: Minor
Fix For: 3.1.1, 3.2.0
Attachments: HBaseQPC.java, zookeeper-279.patch, zookeeper-279.patch
We would like to define certain parts of ZooKeeper's configuration using
variables that get substituted. For example, we want the ZooKeeper quorum to
be able to use a dataDir configured per user. In other words, something like:
tickTime=2000
dataDir=/tmp/zookeeper-${user.name}
clientPort=2181
initLimit=5
syncLimit=2
server.1=zoo1:2888:3888
server.2=zoo2:2888:3888
server.3=zoo3:2888:3888
I think Java already has a system for configuration that allows something
like this using Properties?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-279) Allow specialization of quorum config parsing (e.g. variable expansion in zoo.cfg)
[
https://issues.apache.org/jira/browse/ZOOKEEPER-279?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick Hunt updated ZOOKEEPER-279:
---
Resolution: Fixed
Hadoop Flags: [Reviewed]
Status: Resolved (was: Patch Available)
Committed revision 750597. (3.1 branch)
Committed revision 750599. (mainline - 3.2)
Thanks Jean-Daniel!
Allow specialization of quorum config parsing (e.g. variable expansion in
zoo.cfg)
--
Key: ZOOKEEPER-279
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-279
Project: Zookeeper
Issue Type: Improvement
Affects Versions: 3.1.0
Reporter: Nitay Joffe
Assignee: Jean-Daniel Cryans
Priority: Minor
Fix For: 3.1.1, 3.2.0
Attachments: HBaseQPC.java, zookeeper-279.patch, zookeeper-279.patch
We would like to define certain parts of ZooKeeper's configuration using
variables that get substituted. For example, we want the ZooKeeper quorum to
be able to use a dataDir configured per user. In other words, something like:
tickTime=2000
dataDir=/tmp/zookeeper-${user.name}
clientPort=2181
initLimit=5
syncLimit=2
server.1=zoo1:2888:3888
server.2=zoo2:2888:3888
server.3=zoo3:2888:3888
I think Java already has a system for configuration that allows something
like this using Properties?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-281) autoreconf fails for /zookeeper-3.0.1/src/c/
[ https://issues.apache.org/jira/browse/ZOOKEEPER-281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12679393#action_12679393 ] Mahadev konar commented on ZOOKEEPER-281: - +1 for the patch... autoreconf fails for /zookeeper-3.0.1/src/c/ Key: ZOOKEEPER-281 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-281 Project: Zookeeper Issue Type: Bug Components: c client Affects Versions: 3.0.1 Environment: Linux dememax-laptop 2.6.27-gentoo-r8 #2 SMP Fri Jan 23 13:42:35 MSK 2009 i686 Intel(R) Core(TM)2 CPU T5600 @ 1.83GHz GenuineIntel GNU/Linux autoconf (GNU Autoconf) 2.63 automake (GNU automake) 1.10.2 m4 (GNU M4) 1.4.11 aclocal (GNU automake) 1.10.2 ltmain.sh (GNU libtool) 1.5.26 (1.1220.2.493 2008/02/01 16:58:18) basename (GNU coreutils) 6.10 gettext (GNU gettext-runtime) 0.17 GNU ld (GNU Binutils) 2.18 Reporter: Maxim P. Dementiev Assignee: Patrick Hunt Fix For: 3.2.0 Attachments: autoreconf.log, configure-autoreconf-2.63.gz, configure.gz, ZOOKEEPER-281.patch autoreconf -i -f -v autoreconf-2.63: Entering directory `.' autoreconf-2.63: configure.ac: not using Gettext autoreconf-2.63: running: aclocal --force configure.ac:21: error: AC_SUBST: `DX_FLAG_[]DX_CURRENT_FEATURE' is not a valid shell variable name acinclude.m4:77: DX_REQUIRE_PROG is expanded from... acinclude.m4:117: DX_ARG_ABLE is expanded from... acinclude.m4:178: DX_INIT_DOXYGEN is expanded from... configure.ac:21: the top level autom4te-2.63: /usr/bin/m4 failed with exit status: 1 aclocal-1.10: autom4te failed with exit status: 1 autoreconf-2.63: aclocal failed with exit status: 1 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-329) document how to integrate 3rd party authentication into ZK server ACLs
[ https://issues.apache.org/jira/browse/ZOOKEEPER-329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Hunt updated ZOOKEEPER-329: --- Fix Version/s: (was: 3.1.1) document how to integrate 3rd party authentication into ZK server ACLs -- Key: ZOOKEEPER-329 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-329 Project: Zookeeper Issue Type: Improvement Components: documentation Reporter: Patrick Hunt Priority: Minor Fix For: 3.2.0 the docs mention that zk supports pluggable auth schemes but doesn't detail the API/examples. We should add this to the docs. -- 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 ] Mahadev konar updated ZOOKEEPER-318: Resolution: Fixed Hadoop Flags: [Reviewed] Status: Resolved (was: Patch Available) I just committed this. Thnaks chris. 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 Assignee: Chris Darroch Fix For: 3.2.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.
