[jira] [Created] (ZOOKEEPER-4490) Public Clover results to SonarQube
Tamas Penzes created ZOOKEEPER-4490: --- Summary: Public Clover results to SonarQube Key: ZOOKEEPER-4490 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-4490 Project: ZooKeeper Issue Type: Improvement Components: build Reporter: Tamas Penzes Assignee: Tamas Penzes -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (ZOOKEEPER-3958) Update dependency versions and eliminate java docs warnings
Tamas Penzes created ZOOKEEPER-3958: --- Summary: Update dependency versions and eliminate java docs warnings Key: ZOOKEEPER-3958 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3958 Project: ZooKeeper Issue Type: Improvement Components: server Affects Versions: 3.7.0 Reporter: Tamas Penzes Assignee: Tamas Penzes We have quite many outdated dependency which can be updated and also a few warnings during the build of JavaDocs. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (ZOOKEEPER-3956) Remove json-simple from ZooKeeper
Tamas Penzes created ZOOKEEPER-3956: --- Summary: Remove json-simple from ZooKeeper Key: ZOOKEEPER-3956 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3956 Project: ZooKeeper Issue Type: Improvement Components: contrib, server Affects Versions: 3.7.0 Reporter: Tamas Penzes Assignee: Tamas Penzes In ZooKeeper server we only use one class' one method from json-simple in SnapshotFormatter. I don't think it's worth to keep it that way as it is an additional, not maintained dependency and for generating JSON we have Jackson2 in ZooKeeper anyway. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (ZOOKEEPER-3953) Update hamcrest-library to version 2.2
Tamas Penzes created ZOOKEEPER-3953: --- Summary: Update hamcrest-library to version 2.2 Key: ZOOKEEPER-3953 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3953 Project: ZooKeeper Issue Type: Sub-task Affects Versions: 3.7.0 Reporter: Tamas Penzes Assignee: Tamas Penzes We use a really old version of hamcrest-library where we could use a newer one (version 2.2 instead of 1.3). Time to update it. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (ZOOKEEPER-3952) Remove commons-lang fron ZooKeeper
Tamas Penzes created ZOOKEEPER-3952: --- Summary: Remove commons-lang fron ZooKeeper Key: ZOOKEEPER-3952 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3952 Project: ZooKeeper Issue Type: Improvement Components: server Affects Versions: 3.6.2 Reporter: Tamas Penzes Assignee: Tamas Penzes We barely use commons-lang and the functionality we use from it is limited to only two functions whose can be easily replaced with standard Java based implementation. This way we can reduce the number of dependencies we have. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (ZOOKEEPER-3941) Upgrade commons-cli to 1.4
Tamas Penzes created ZOOKEEPER-3941: --- Summary: Upgrade commons-cli to 1.4 Key: ZOOKEEPER-3941 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3941 Project: ZooKeeper Issue Type: Improvement Components: server Reporter: Tamas Penzes Assignee: Tamas Penzes commons-cli 1.2 was released in 2009, time to upgrade it to the newest version (1.4). To avoid deprecation messages we have to upgrade the Java code too. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (ZOOKEEPER-3872) Upgrade jUnit in ZooKeeper-server
Tamas Penzes created ZOOKEEPER-3872: --- Summary: Upgrade jUnit in ZooKeeper-server Key: ZOOKEEPER-3872 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3872 Project: ZooKeeper Issue Type: Sub-task Components: server Reporter: Tamas Penzes Update test code to use jUnit 5 in server project -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (ZOOKEEPER-3862) Re-enable deprecation check after finishing jUnit upgrade
Tamas Penzes created ZOOKEEPER-3862: --- Summary: Re-enable deprecation check after finishing jUnit upgrade Key: ZOOKEEPER-3862 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3862 Project: ZooKeeper Issue Type: Sub-task Components: tests Reporter: Tamas Penzes In ZOOKEEPER-3850 deprecation check got disabled as it alerted for jUnit code. After all the testclasses will get updated to use jUnit5 methods the deprecation check must be re-enabled. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (ZOOKEEPER-3857) ZooKeeper 3.6 doesn't build after Curator test committed
Tamas Penzes created ZOOKEEPER-3857: --- Summary: ZooKeeper 3.6 doesn't build after Curator test committed Key: ZOOKEEPER-3857 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3857 Project: ZooKeeper Issue Type: Bug Reporter: Tamas Penzes Assignee: Tamas Penzes -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (ZOOKEEPER-3855) Upgrade jUnit in ZooKeeper-Metrics-providers
Tamas Penzes created ZOOKEEPER-3855: --- Summary: Upgrade jUnit in ZooKeeper-Metrics-providers Key: ZOOKEEPER-3855 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3855 Project: ZooKeeper Issue Type: Sub-task Components: metric system Reporter: Tamas Penzes Assignee: Tamas Penzes Update test code to use jUnit 5 in metrics providers -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (ZOOKEEPER-3854) Upgrade jUnit in ZooKeeper-Recipes
Tamas Penzes created ZOOKEEPER-3854: --- Summary: Upgrade jUnit in ZooKeeper-Recipes Key: ZOOKEEPER-3854 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3854 Project: ZooKeeper Issue Type: Sub-task Components: recipes Reporter: Tamas Penzes Assignee: Tamas Penzes Update test code to use jUnit 5 in recipes -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (ZOOKEEPER-3853) Upgrade jUnit in ZooKeeper-IT
Tamas Penzes created ZOOKEEPER-3853: --- Summary: Upgrade jUnit in ZooKeeper-IT Key: ZOOKEEPER-3853 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3853 Project: ZooKeeper Issue Type: Sub-task Components: tests Reporter: Tamas Penzes Assignee: Tamas Penzes Update test code to use jUnit 5 in IT sub-project -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (ZOOKEEPER-3852) Upgrade jUnit in ZooKeeper-Jute
Tamas Penzes created ZOOKEEPER-3852: --- Summary: Upgrade jUnit in ZooKeeper-Jute Key: ZOOKEEPER-3852 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3852 Project: ZooKeeper Issue Type: Sub-task Components: jute Reporter: Tamas Penzes Assignee: Tamas Penzes Upgrade test code to use jUnit 5 in ZooKeeper-Jute. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (ZOOKEEPER-3851) Upgrade jUnit in ZooKeeper-Contrib
Tamas Penzes created ZOOKEEPER-3851: --- Summary: Upgrade jUnit in ZooKeeper-Contrib Key: ZOOKEEPER-3851 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3851 Project: ZooKeeper Issue Type: Sub-task Components: contrib Reporter: Tamas Penzes Assignee: Tamas Penzes Update test code to use jUnit 5 in contrib projects -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (ZOOKEEPER-3850) Update jUnit to 5.6
Tamas Penzes created ZOOKEEPER-3850: --- Summary: Update jUnit to 5.6 Key: ZOOKEEPER-3850 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3850 Project: ZooKeeper Issue Type: Sub-task Components: tests Reporter: Tamas Penzes Assignee: Tamas Penzes -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (ZOOKEEPER-3732) Update jUnit version to 5.6
Tamas Penzes created ZOOKEEPER-3732: --- Summary: Update jUnit version to 5.6 Key: ZOOKEEPER-3732 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3732 Project: ZooKeeper Issue Type: Improvement Affects Versions: 3.6.0 Reporter: Tamas Penzes Assignee: Tamas Penzes jUnit 4 is limited to Java 7 features, jUnit 5 can use new elements of JDK8. It's time to go forward and update our jUnit version to 5.6. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (ZOOKEEPER-2359) ZooKeeper client has unnecessary logs for watcher removal errors
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2359?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16847471#comment-16847471
]
Tamas Penzes commented on ZOOKEEPER-2359:
-
[~ronald.findling] please check fix version.
*Fix Version/s:*
[3.5.4|https://issues.apache.org/jira/issues/?jql=project+%3D+ZOOKEEPER+AND+fixVersion+%3D+3.5.4],
[3.6.0|https://issues.apache.org/jira/issues/?jql=project+%3D+ZOOKEEPER+AND+fixVersion+%3D+3.6.0]
So you have to see the problem in 3.5.3-beta as it got fixed later.
> ZooKeeper client has unnecessary logs for watcher removal errors
>
>
> Key: ZOOKEEPER-2359
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2359
> Project: ZooKeeper
> Issue Type: Improvement
> Components: java client
>Affects Versions: 3.5.1
>Reporter: Jordan Zimmerman
>Assignee: Jordan Zimmerman
>Priority: Major
> Fix For: 3.5.4, 3.6.0
>
> Attachments: ZOOKEEPER-2359.patch
>
>
> ClientCnxn.java logs errors during watcher removal:
> LOG.error("Failed to find watcher!", nwe);
> LOG.error("Exception when removing watcher", ke);
> An error code/exception is generated so the logs are noisy and unnecessary.
> If the client handles the error there's still a log message. This is
> different than other APIs. These logs should be removed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (ZOOKEEPER-102) Need to replace Jute with supported code
[ https://issues.apache.org/jira/browse/ZOOKEEPER-102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16827101#comment-16827101 ] Tamas Penzes edited comment on ZOOKEEPER-102 at 4/26/19 4:23 PM: - Based on the size of the task I think it would worth to discuss which option to choose. [~maoling] would you start a DISCUSS thread on the dev mailing list to collect the pros and cons of the options? was (Author: tamaas): Based on the size of the task I think it would worth to discuss which option to choose. [~maoling] would you start a DISCUSS thread on the mailing list to collect the pros and cons of the options? > Need to replace Jute with supported code > > > Key: ZOOKEEPER-102 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-102 > Project: ZooKeeper > Issue Type: Improvement >Reporter: Benjamin Reed >Priority: Major > Fix For: 4.0.0 > > > ZooKeeper currently uses Jute to serialize objects to put on the wire and on > disk. We pulled Jute out of Hadoop and added a C binding. Both versions of > Jute have evolved (although Hadoop still doesn't have a C binding). It would > be nice to use a more standard serialization library. Some options include > Thrift or Google's protocol buffers. > Our main requirements would be Java and C bindings and good performance. (For > example, serializing to XML would give us incredibly bad performance and > would not be acceptible!) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ZOOKEEPER-102) Need to replace Jute with supported code
[ https://issues.apache.org/jira/browse/ZOOKEEPER-102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16827101#comment-16827101 ] Tamas Penzes commented on ZOOKEEPER-102: Based on the size of the task I think it would worth to discuss which option to choose. [~maoling] would you start a DISCUSS thread on the mailing list to collect the pros and cons of the options? > Need to replace Jute with supported code > > > Key: ZOOKEEPER-102 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-102 > Project: ZooKeeper > Issue Type: Improvement >Reporter: Benjamin Reed >Priority: Major > Fix For: 4.0.0 > > > ZooKeeper currently uses Jute to serialize objects to put on the wire and on > disk. We pulled Jute out of Hadoop and added a C binding. Both versions of > Jute have evolved (although Hadoop still doesn't have a C binding). It would > be nice to use a more standard serialization library. Some options include > Thrift or Google's protocol buffers. > Our main requirements would be Java and C bindings and good performance. (For > example, serializing to XML would give us incredibly bad performance and > would not be acceptible!) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (ZOOKEEPER-3345) Masters
[ https://issues.apache.org/jira/browse/ZOOKEEPER-3345?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Penzes resolved ZOOKEEPER-3345. - Resolution: Invalid > Masters > --- > > Key: ZOOKEEPER-3345 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3345 > Project: ZooKeeper > Issue Type: Bug > Components: build-infrastructure >Affects Versions: 4.0.0 >Reporter: Simon poortman >Priority: Critical > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (ZOOKEEPER-3346) Simon poortman
[ https://issues.apache.org/jira/browse/ZOOKEEPER-3346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Penzes resolved ZOOKEEPER-3346. - Resolution: Invalid SPAM. It happens on HBase too. > Simon poortman > -- > > Key: ZOOKEEPER-3346 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3346 > Project: ZooKeeper > Issue Type: Bug > Components: build-infrastructure >Affects Versions: 4.0.0 >Reporter: Simon poortman >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (ZOOKEEPER-3053) add remove watches capabilities to the c cli
[ https://issues.apache.org/jira/browse/ZOOKEEPER-3053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Penzes reassigned ZOOKEEPER-3053: --- Assignee: Balazs Meszaros > add remove watches capabilities to the c cli > > > Key: ZOOKEEPER-3053 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3053 > Project: ZooKeeper > Issue Type: Bug > Components: c client, tests >Affects Versions: 3.6.0, 3.5.5 >Reporter: Patrick Hunt >Assignee: Balazs Meszaros >Priority: Major > Labels: newbie, remove_watches > > It would be good to be able to exercise the remove watches functionality from > the c client cli. Mostly for testing purposes. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (ZOOKEEPER-834) Allow ephemeral znodes to have children created only by the owner session.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-834?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Penzes updated ZOOKEEPER-834: --- Labels: container_znode_type (was: ) > 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 >Assignee: Rakesh R >Priority: Major > Labels: container_znode_type > Fix For: 3.6.0 > > Attachments: ZOOKEEPER-834.1.patch, ZOOKEEPER-834.2.patch, > ZOOKEEPER-834.patch, ZOOKEEPER-834.patch > > > 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 was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (ZOOKEEPER-2591) The deletion of Container znode doesn't check ACL delete permission
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2591?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Penzes updated ZOOKEEPER-2591:
Labels: container_znode_type (was: )
> The deletion of Container znode doesn't check ACL delete permission
> ---
>
> Key: ZOOKEEPER-2591
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2591
> Project: ZooKeeper
> Issue Type: Bug
> Components: security, server
>Reporter: Edward Ribeiro
>Assignee: Edward Ribeiro
>Priority: Major
> Labels: container_znode_type
>
> Container nodes check the ACL before creation, but the deletion doesn't check
> the ACL rights. The code below succeeds even tough we removed ACL access
> permissions for "/a".
> {code}
> zk.create("/a", null, Ids.OPEN_ACL_UNSAFE, CreateMode.CONTAINER);
> ArrayList list = new ArrayList<>();
> list.add(new ACL(0, Ids.ANYONE_ID_UNSAFE));
> zk.setACL("/", list, -1);
> zk.delete("/a", -1);
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (ZOOKEEPER-2192) Port "Introduce new ZNode type: container" to 3.4.x
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Penzes updated ZOOKEEPER-2192: Labels: container_znode_type (was: ) > Port "Introduce new ZNode type: container" to 3.4.x > --- > > Key: ZOOKEEPER-2192 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2192 > Project: ZooKeeper > Issue Type: Sub-task > Components: c client, java client, server >Affects Versions: 3.4.6 >Reporter: Jordan Zimmerman >Assignee: Jordan Zimmerman >Priority: Major > Labels: container_znode_type > Attachments: ZOOKEEPER-2192.patch, ZOOKEEPER-2192.patch > > > ZOOKEEPER-2163 applies to the trunk branch. This feature is too needed to > wait for 3.5.x. So, port the feature to the 3.4.x branch so it can be > released ahead of 3.5.x. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (ZOOKEEPER-723) ephemeral parent znodes
[ https://issues.apache.org/jira/browse/ZOOKEEPER-723?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Penzes updated ZOOKEEPER-723: --- Labels: container_znode_type (was: ) > ephemeral parent znodes > --- > > Key: ZOOKEEPER-723 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-723 > Project: ZooKeeper > Issue Type: New Feature > Components: server >Reporter: Benjamin Reed >Assignee: Daniel Gómez Ferro >Priority: Major > Labels: container_znode_type > Attachments: ZOOKEEPER-723.patch, ZOOKEEPER-723.patch > > > 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 was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (ZOOKEEPER-2168) Add C APIs for new createContainer Methods
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Penzes updated ZOOKEEPER-2168: Labels: container_znode_type pull-request-available (was: pull-request-available) > Add C APIs for new createContainer Methods > -- > > Key: ZOOKEEPER-2168 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2168 > Project: ZooKeeper > Issue Type: Sub-task > Components: c client >Affects Versions: 3.5.0 >Reporter: Jordan Zimmerman >Assignee: Balazs Meszaros >Priority: Major > Labels: container_znode_type, pull-request-available > Fix For: 3.6.0, 3.5.5 > > Time Spent: 1h 40m > Remaining Estimate: 0h > > ZOOKEEPER-2163 adds new client methods to create containers. These need to be > exposed in the C client as well. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (ZOOKEEPER-2163) Introduce new ZNode type: container
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Penzes updated ZOOKEEPER-2163:
Labels: container_znode_type pull-request-available (was:
pull-request-available)
> Introduce new ZNode type: container
> ---
>
> Key: ZOOKEEPER-2163
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2163
> Project: ZooKeeper
> Issue Type: New Feature
> Components: c client, java client, server
>Affects Versions: 3.5.0
>Reporter: Jordan Zimmerman
>Assignee: Jordan Zimmerman
>Priority: Major
> Labels: container_znode_type, pull-request-available
> Fix For: 3.5.1, 3.6.0
>
> Attachments: zookeeper-2163.10.patch, zookeeper-2163.11.patch,
> zookeeper-2163.12.patch, zookeeper-2163.13.patch, zookeeper-2163.14.patch,
> zookeeper-2163.15.patch, zookeeper-2163.3.patch, zookeeper-2163.5.patch,
> zookeeper-2163.6.patch, zookeeper-2163.7.patch, zookeeper-2163.8.patch,
> zookeeper-2163.9.patch
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> BACKGROUND
>
> A recurring problem for ZooKeeper users is garbage collection of parent
> nodes. Many recipes (e.g. locks, leaders, etc.) call for the creation of a
> parent node under which participants create sequential nodes. When the
> participant is done, it deletes its node. In practice, the ZooKeeper tree
> begins to fill up with orphaned parent nodes that are no longer needed. The
> ZooKeeper APIs don’t provide a way to clean these. Over time, ZooKeeper can
> become unstable due to the number of these nodes.
> CURRENT SOLUTIONS
> ===
> Apache Curator has a workaround solution for this by providing the Reaper
> class which runs in the background looking for orphaned parent nodes and
> deleting them. This isn’t ideal and it would be better if ZooKeeper supported
> this directly.
> PROPOSAL
> =
> ZOOKEEPER-723 and ZOOKEEPER-834 have been proposed to allow EPHEMERAL nodes
> to contain child nodes. This is not optimum as EPHEMERALs are tied to a
> session and the general use case of parent nodes is for PERSISTENT nodes.
> This proposal adds a new node type, CONTAINER. A CONTAINER node is the same
> as a PERSISTENT node with the additional property that when its last child is
> deleted, it is deleted (and CONTAINER nodes recursively up the tree are
> deleted if empty).
> CANONICAL USAGE
>
> {code}
> while ( true) { // or some reasonable limit
> try {
> zk.create(path, ...);
> break;
> } catch ( KeeperException.NoNodeException e ) {
> try {
> zk.createContainer(containerPath, ...);
> } catch ( KeeperException.NodeExistsException ignore) {
>}
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (ZOOKEEPER-2609) Add TTL Node APIs to C client
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2609?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Penzes reassigned ZOOKEEPER-2609: --- Assignee: Balazs Meszaros > Add TTL Node APIs to C client > - > > Key: ZOOKEEPER-2609 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2609 > Project: ZooKeeper > Issue Type: Sub-task > Components: c client, java client, jute, server >Reporter: Jordan Zimmerman >Assignee: Balazs Meszaros >Priority: Major > Labels: ttl_nodes > Fix For: 3.6.0 > > > Need to update the C lib to have the TTL node option -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (ZOOKEEPER-2168) Add C APIs for new createContainer Methods
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Penzes reassigned ZOOKEEPER-2168: --- Assignee: Balazs Meszaros > Add C APIs for new createContainer Methods > -- > > Key: ZOOKEEPER-2168 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2168 > Project: ZooKeeper > Issue Type: Sub-task > Components: c client >Affects Versions: 3.5.0 >Reporter: Jordan Zimmerman >Assignee: Balazs Meszaros >Priority: Major > Labels: pull-request-available > Time Spent: 20m > Remaining Estimate: 0h > > ZOOKEEPER-2163 adds new client methods to create containers. These need to be > exposed in the C client as well. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (ZOOKEEPER-2903) Port ZOOKEEPER-2901 to 3.5.4
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2903?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Penzes updated ZOOKEEPER-2903: Labels: pull-request-available ttl_nodes (was: pull-request-available) > Port ZOOKEEPER-2901 to 3.5.4 > > > Key: ZOOKEEPER-2903 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2903 > Project: ZooKeeper > Issue Type: Sub-task > Components: server >Affects Versions: 3.5.3 >Reporter: Jordan Zimmerman >Assignee: Jordan Zimmerman >Priority: Blocker > Labels: pull-request-available, ttl_nodes > Fix For: 3.5.4 > > Time Spent: 10m > Remaining Estimate: 0h > > The TTL/Server ID bug is quite serious and should be back-ported to the 3.5.x > branch -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (ZOOKEEPER-3038) Cleanup some nitpicks in TTL implementation
[ https://issues.apache.org/jira/browse/ZOOKEEPER-3038?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Penzes updated ZOOKEEPER-3038: Labels: ttl_nodes (was: ) > Cleanup some nitpicks in TTL implementation > --- > > Key: ZOOKEEPER-3038 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3038 > Project: ZooKeeper > Issue Type: Bug > Components: server >Affects Versions: 3.5.3 >Reporter: Andor Molnar >Assignee: Andor Molnar >Priority: Major > Labels: ttl_nodes > Fix For: 3.5.4, 3.6.0 > > > A few nitpicks which needs to be cleaned up: > 1. Rename OldEphemeralType --> EphemeralTypeEmulate353 > 2. Remove unused method: getTTL() > 3. Remove unused import from QuorumPeer > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (ZOOKEEPER-2797) Invalid TTL from misbehaving client nukes zookeeper
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2797?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Penzes updated ZOOKEEPER-2797: Labels: ttl_nodes (was: ) > Invalid TTL from misbehaving client nukes zookeeper > --- > > Key: ZOOKEEPER-2797 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2797 > Project: ZooKeeper > Issue Type: Bug > Components: security, server >Affects Versions: 3.6.0 >Reporter: Patrick White >Assignee: Patrick White >Priority: Major > Labels: ttl_nodes > Fix For: 3.5.4, 3.6.0 > > > I was adding container and TTL support to kazoo, and managed to screw > something up which set the TTL to a negative value. This invalid TTL blew up > the commit processor, and got written to the log, preventing the zookeepers > from starting back up. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (ZOOKEEPER-2609) Add TTL Node APIs to C client
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2609?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Penzes updated ZOOKEEPER-2609: Labels: ttl_nodes (was: ) > Add TTL Node APIs to C client > - > > Key: ZOOKEEPER-2609 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2609 > Project: ZooKeeper > Issue Type: Sub-task > Components: c client, java client, jute, server >Reporter: Jordan Zimmerman >Priority: Major > Labels: ttl_nodes > Fix For: 3.6.0 > > > Need to update the C lib to have the TTL node option -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (ZOOKEEPER-1925) Time to Live or auto expiration of zookeeper node
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1925?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Penzes updated ZOOKEEPER-1925: Labels: ttl_nodes (was: ) > Time to Live or auto expiration of zookeeper node > - > > Key: ZOOKEEPER-1925 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1925 > Project: ZooKeeper > Issue Type: New Feature >Reporter: Omkar Vinit Joshi >Priority: Major > Labels: ttl_nodes > Fix For: 3.6.0 > > > Today whenever a znode is created; it stays there for ever. We all know that > there is a limitation in terms of how many nodes a system can handle. It > would be nice to have a way to specify expiry time for every znode thereby > stale zondes are cleandup automatically after sufficiently large time. any > thoughts? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (ZOOKEEPER-2543) Add C API for creating nodes with TTL
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2543?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Penzes updated ZOOKEEPER-2543: Labels: ttl_nodes (was: ) > Add C API for creating nodes with TTL > - > > Key: ZOOKEEPER-2543 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2543 > Project: ZooKeeper > Issue Type: New Feature > Components: c client >Affects Versions: 3.6.0 >Reporter: Michael Han >Priority: Major > Labels: ttl_nodes > Fix For: 3.6.0 > > > ZOOKEEPER-2169 introduces a new feature for creation nodes with TTL, which is > supported by Java client with new Java API. Similar API should be added to C > client as well. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (ZOOKEEPER-2901) Session ID that is negative causes mis-calculation of Ephemeral Type
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2901?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Penzes updated ZOOKEEPER-2901:
Labels: ttl_nodes (was: )
> Session ID that is negative causes mis-calculation of Ephemeral Type
>
>
> Key: ZOOKEEPER-2901
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2901
> Project: ZooKeeper
> Issue Type: Bug
> Components: server
>Affects Versions: 3.5.3
> Environment: Running 3.5.3-beta in Docker container
>Reporter: Mark Johnson
>Assignee: Jordan Zimmerman
>Priority: Blocker
> Labels: ttl_nodes
> Fix For: 3.5.4, 3.6.0
>
>
> In the code that determines the EphemeralType it is looking at the owner
> (which is the client ID or connection ID):
> EphemeralType.java:
>public static EphemeralType get(long ephemeralOwner) {
>if (ephemeralOwner == CONTAINER_EPHEMERAL_OWNER) {
>return CONTAINER;
>}
>if (ephemeralOwner < 0) {
>return TTL;
>}
>return (ephemeralOwner == 0) ? VOID : NORMAL;
>}
> However my connection ID is:
> header.getClientId(): -720548323429908480
> This causes the code to think this is a TTL Ephemeral node instead of a
> NORMAL Ephemeral node.
> This also explains why this is random - if my client ID is non-negative
> then the node gets added correctly.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (ZOOKEEPER-3113) EphemeralType.get() fails to verify ephemeralOwner when currentElapsedTime() is small enough
[ https://issues.apache.org/jira/browse/ZOOKEEPER-3113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Penzes updated ZOOKEEPER-3113: Labels: pull-request-available ttl_nodes (was: pull-request-available) > EphemeralType.get() fails to verify ephemeralOwner when currentElapsedTime() > is small enough > > > Key: ZOOKEEPER-3113 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3113 > Project: ZooKeeper > Issue Type: Bug > Components: server >Affects Versions: 3.5.4, 3.6.0 >Reporter: Andor Molnar >Assignee: Andor Molnar >Priority: Critical > Labels: pull-request-available, ttl_nodes > Fix For: 3.6.0, 3.5.5 > > Time Spent: 4.5h > Remaining Estimate: 0h > > EphemeralTypeTest.testServerIds() unit test fails on some systems that > System.nanoTime() is smaller than a certain value. > The test generates ephemeralOwner in the old way (pre ZOOKEEPER-2901) without > enabling the emulation flag and asserts for exception to be thrown when > serverId == 255. This is right. ZooKeeper should fail on this case, because > serverId cannot be larger than 254 if extended types are enabled. In this > case ephemeralOwner with 0xff in the most significant byte indicates an > extended type. > The logic which does the validation is in EphemeralType.get(). > It checks 2 things: > * the extended type byte is set: 0xff, > * reserved bits (next 2 bytes) corresponds to a valid extended type. > Here is the problem: currently we only have 1 extended type: TTL with value > of 0x in the reserved bits. > Logic expects that if we have anything different from it in the reserved > bits, the ephemeralOwner is invalid and exception should be thrown. That's > what the test asserts for and it works on most systems, because the timestamp > part of the sessionId usually have some bits in the reserved bits as well > which eventually will be larger than 0, so the value is unsupported. > I think the problem is twofold: > * Either if we have more extended types, we'll increase the possibility that > this logic will accept invalid sessionIds (as long as reserved bits indicate > a valid extended type), > * Or (which happens on some systems) if the currentElapsedTime (timestamp > part of sessionId) is small enough and doesn't occupy reserved bits, this > logic will accept the invalid sessionId. > Unfortunately I cannot repro the problem yet: it constantly happens on a > specific Jenkins slave, but even with the same distro and same JDK version I > cannot reproduce the same nanoTime() values. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (ZOOKEEPER-2608) Create CLI option for TTL ephemerals
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2608?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Penzes updated ZOOKEEPER-2608: Labels: ttl_nodes (was: ) > Create CLI option for TTL ephemerals > > > Key: ZOOKEEPER-2608 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2608 > Project: ZooKeeper > Issue Type: Sub-task > Components: c client, java client, jute, server >Reporter: Camille Fournier >Assignee: Jordan Zimmerman >Priority: Major > Labels: ttl_nodes > Fix For: 3.6.0 > > Attachments: ZOOKEEPER-2608-2.patch, ZOOKEEPER-2608-3.patch, > ZOOKEEPER-2608.patch > > > Need to update CreateCommand to have the TTL node option -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (ZOOKEEPER-2719) Port ZOOKEEPER-2169 (TTL Nodes) to 3.5 branch
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Penzes updated ZOOKEEPER-2719: Labels: ttl_nodes (was: ) > Port ZOOKEEPER-2169 (TTL Nodes) to 3.5 branch > - > > Key: ZOOKEEPER-2719 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2719 > Project: ZooKeeper > Issue Type: New Feature > Components: java client, server >Reporter: Jordan Zimmerman >Assignee: Jordan Zimmerman >Priority: Major > Labels: ttl_nodes > Fix For: 3.5.3 > > > ZOOKEEPER-2169 is a useful feature that should be deployed sooner than later. > Take the work done in the master branch and port it to the 3.5 branch -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (ZOOKEEPER-2169) Enable creation of nodes with TTLs
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Penzes updated ZOOKEEPER-2169: Labels: ttl_nodes (was: ) > Enable creation of nodes with TTLs > -- > > Key: ZOOKEEPER-2169 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2169 > Project: ZooKeeper > Issue Type: New Feature > Components: c client, java client, jute, server >Affects Versions: 3.6.0 >Reporter: Camille Fournier >Assignee: Jordan Zimmerman >Priority: Major > Labels: ttl_nodes > Fix For: 3.6.0 > > Attachments: ZOOKEEPER-2169-2.patch, ZOOKEEPER-2169-3.patch, > ZOOKEEPER-2169-4.patch, ZOOKEEPER-2169-5.patch, ZOOKEEPER-2169-6.patch, > ZOOKEEPER-2169-7.patch, ZOOKEEPER-2169-8.patch, ZOOKEEPER-2169-9.patch, > ZOOKEEPER-2169.patch > > > As a user, I would like to be able to create a node that is NOT tied to a > session but that WILL expire automatically if action is not taken by some > client within a time window. > I propose this to enable clients interacting with ZK via http or other "thin > clients" to create ephemeral-like nodes. > Some ideas for the design, up for discussion: > The node should support all normal ZK node operations including ACLs, > sequential key generation, etc, however, it should not support the ephemeral > flag. The node will be created with a TTL that is updated via a refresh > operation. > The ZK quorum will watch this node similarly to the way that it watches for > session liveness; if the node is not refreshed within the TTL, it will expire. > QUESTIONS: > 1) Should we let the refresh operation set the TTL to a different base value? > 2) If so, should the setting of the TTL to a new base value cause a watch to > fire? > 3) Do we want to allow these nodes to have children or prevent this similar > to ephemeral nodes? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (ZOOKEEPER-2611) zoo_remove_watchers - can remove the wrong watch
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2611?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Penzes updated ZOOKEEPER-2611: Labels: remove_watches (was: ) > zoo_remove_watchers - can remove the wrong watch > - > > Key: ZOOKEEPER-2611 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2611 > Project: ZooKeeper > Issue Type: Bug > Components: c client >Reporter: Eyal leshem >Assignee: Eyal leshem >Priority: Critical > Labels: remove_watches > Fix For: 3.5.3, 3.6.0 > > Attachments: ZOOKEEPER-2611.patch > > > The actual problem is in the function "removeWatcherFromList" - > That when we check if we need to delete the watch - we compare the > WatcherCtx to one node before the one we want to delete.. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (ZOOKEEPER-2586) zoo_aremove_watchers() does not remove a watch of path has more than one watch
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2586?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Penzes updated ZOOKEEPER-2586:
Labels: remove_watches (was: )
> zoo_aremove_watchers() does not remove a watch of path has more than one watch
> --
>
> Key: ZOOKEEPER-2586
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2586
> Project: ZooKeeper
> Issue Type: Bug
>Reporter: prashant
>Priority: Major
> Labels: remove_watches
>
> three issues
> 1)zoo_aremove_watchers() does not remove a watch if path has more than one
> watch.
> but it works in below cases.
> it removes watch if path has only one watch.
> and it removes all watches if watcher function arguments is NULL.
> Seen in
> zookeeper.version=3.5.1-alpha--1, built on 06/09/2016 18:31 GMT
> Not sure if this is fixed in later versions.
> 2) If zoo_aremove_watchers() is called with local=1, then client hangs in
> waiting for mutex in mt_adaptor.c:102
> void notify_sync_completion(struct sync_completion *sc)
> {
> pthread_mutex_lock(>lock);
> ...
> 3) Acts like sync API if no node and no watcher on path.
> it does not call async completion callback in this case.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (ZOOKEEPER-1909) removeWatches doesn't return NOWATCHER when there is no watch set
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1909?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Penzes updated ZOOKEEPER-1909: Labels: remove_watches (was: ) > removeWatches doesn't return NOWATCHER when there is no watch set > - > > Key: ZOOKEEPER-1909 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1909 > Project: ZooKeeper > Issue Type: Bug > Components: server >Affects Versions: 3.5.0 >Reporter: Raul Gutierrez Segales >Assignee: Raul Gutierrez Segales >Priority: Major > Labels: remove_watches > Fix For: 3.5.0 > > Attachments: ZOOKEEPER-1909.patch, ZOOKEEPER-1909.patch, > ZOOKEEPER-1909.patch, ZOOKEEPER-1909.patch > > > ZOOKEEPER-442 introduced support for a new opcode: removeWatches. The way it > was implemented though, implies that you need to check on the client side if > a watch/watcher is set *before* you send your request to the server. If you > don't, ZK will just swallow your request and won't return an error code if > there isn't a watch set for that path. > I noticed this whilst implementing removeWatches for Kazoo [1]. As mentioned, > I guess it could be expected that clients should do the check on their side > but I think that the correct thing would to have the server do the validation > and return the error code accordingly as well. > [~rakeshr], [~phunt]: thoughts? > [1] > https://github.com/rgs1/kazoo/commit/44ca48e975aeea3fd0664fe13136a72caf89e54f -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (ZOOKEEPER-1830) Support command line shell for removing watches
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1830?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Penzes updated ZOOKEEPER-1830: Labels: remove_watches (was: ) > Support command line shell for removing watches > --- > > Key: ZOOKEEPER-1830 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1830 > Project: ZooKeeper > Issue Type: Sub-task >Reporter: Rakesh R >Assignee: Rakesh R >Priority: Critical > Labels: remove_watches > Fix For: 3.5.0 > > Attachments: ZOOKEEPER-1830.patch, ZOOKEEPER-1830.patch > > > This JIRA to discuss the command line shell for removing watches. Makes it > easier to do ad-hoc testing. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (ZOOKEEPER-1831) Document remove watches details to the guide
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1831?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Penzes updated ZOOKEEPER-1831: Labels: remove_watches (was: ) > Document remove watches details to the guide > > > Key: ZOOKEEPER-1831 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1831 > Project: ZooKeeper > Issue Type: Sub-task > Components: documentation >Reporter: Rakesh R >Assignee: Rakesh R >Priority: Major > Labels: remove_watches > Fix For: 3.5.0 > > Attachments: ZOOKEEPER-1831.patch, ZOOKEEPER-1831.patch > > > This JIRA is for documenting the details of removing the watches -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (ZOOKEEPER-1887) C implementation of removeWatches
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1887?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Penzes updated ZOOKEEPER-1887: Labels: remove_watches (was: ) > C implementation of removeWatches > - > > Key: ZOOKEEPER-1887 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1887 > Project: ZooKeeper > Issue Type: New Feature > Components: c client >Reporter: Raul Gutierrez Segales >Assignee: Raul Gutierrez Segales >Priority: Major > Labels: remove_watches > Fix For: 3.5.0 > > Attachments: ZOOKEEPER-1887.patch, ZOOKEEPER-1887.patch, > ZOOKEEPER-1887.patch > > > This is equivalent for ZOOKEEPER-442's Java impl. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (ZOOKEEPER-1829) Umbrella jira for removing watches that are no longer of interest
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1829?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Penzes updated ZOOKEEPER-1829: Labels: remove_watches (was: ) > Umbrella jira for removing watches that are no longer of interest > - > > Key: ZOOKEEPER-1829 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1829 > Project: ZooKeeper > Issue Type: New Feature > Components: java client, server >Reporter: Rakesh R >Assignee: Rakesh R >Priority: Critical > Labels: remove_watches > Fix For: 3.5.0 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (ZOOKEEPER-2062) RemoveWatchesTest takes forever to run
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2062?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Penzes updated ZOOKEEPER-2062: Labels: remove_watches (was: ) > RemoveWatchesTest takes forever to run > -- > > Key: ZOOKEEPER-2062 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2062 > Project: ZooKeeper > Issue Type: Bug > Components: tests >Affects Versions: 3.5.0 >Reporter: Flavio Junqueira >Assignee: Chris Nauroth >Priority: Major > Labels: remove_watches > Fix For: 3.5.1, 3.6.0 > > Attachments: ZOOKEEPER-2062.001.patch, ZOOKEEPER-2062.002.patch, > ZOOKEEPER-2062.003.patch, ZOOKEEPER-2062.004.patch > > > [junit] Running org.apache.zookeeper.RemoveWatchesTest > [junit] Tests run: 46, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: > 306.188 sec -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (ZOOKEEPER-442) need a way to remove watches that are no longer of interest
[ https://issues.apache.org/jira/browse/ZOOKEEPER-442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Penzes updated ZOOKEEPER-442: --- Labels: remove_watches (was: ) > need a way to remove watches that are no longer of interest > --- > > Key: ZOOKEEPER-442 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-442 > Project: ZooKeeper > Issue Type: Sub-task > Components: java client, server >Reporter: Benjamin Reed >Assignee: Rakesh R >Priority: Critical > Labels: remove_watches > Fix For: 3.5.0 > > Attachments: Remove Watch API.pdf, ZOOKEEPER-442.patch, > ZOOKEEPER-442.patch, ZOOKEEPER-442.patch, ZOOKEEPER-442.patch, > ZOOKEEPER-442.patch, ZOOKEEPER-442.patch, ZOOKEEPER-442.patch, > ZOOKEEPER-442.patch, ZOOKEEPER-442.patch, ZOOKEEPER-442.patch, > ZOOKEEPER-442.patch, ZOOKEEPER-442.patch, ZOOKEEPER-442.patch, > ZOOKEEPER-442.patch, ZOOKEEPER-442.patch > > > currently the only way a watch cleared is to trigger it. we need a way to > enumerate the outstanding watch objects, find watch events the objects are > watching for, and remove interests in an event. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (ZOOKEEPER-1919) Update the C implementation of removeWatches to have it match ZOOKEEPER-1910
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1919?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Penzes updated ZOOKEEPER-1919: Labels: pull-request-available remove_watches (was: pull-request-available) > Update the C implementation of removeWatches to have it match ZOOKEEPER-1910 > > > Key: ZOOKEEPER-1919 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1919 > Project: ZooKeeper > Issue Type: Bug > Components: c client >Affects Versions: 3.5.0 >Reporter: Raul Gutierrez Segales >Assignee: Raul Gutierrez Segales >Priority: Blocker > Labels: pull-request-available, remove_watches > Fix For: 3.6.0, 3.5.5 > > Attachments: ZOOKEEPER-1919.patch, ZOOKEEPER-1919.patch > > Time Spent: 2h > Remaining Estimate: 0h > > See https://issues.apache.org/jira/browse/ZOOKEEPER-1910 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (ZOOKEEPER-1910) RemoveWatches wrongly removes the watcher if multiple watches exists on a path
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1910?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Penzes updated ZOOKEEPER-1910: Labels: remove_watches (was: ) > RemoveWatches wrongly removes the watcher if multiple watches exists on a path > -- > > Key: ZOOKEEPER-1910 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1910 > Project: ZooKeeper > Issue Type: Bug > Components: java client, server >Reporter: Rakesh R >Assignee: Rakesh R >Priority: Major > Labels: remove_watches > Fix For: 3.5.0 > > Attachments: ZOOKEEPER-1910.patch, ZOOKEEPER-1910.patch, > ZOOKEEPER-1910.patch, ZOOKEEPER-1910.patch > > > Consider a case where zkclient has added 2 data watchers(say 'w1' and 'w2') > on '/node1'. > Now user has removed w1, but this is deleting the 'CnxnWatcher' in ZK server > against the "/node1" path. This will affect other data watchers(if any) of > same client on same path. In our case 'w2' would not be notified. > Note: please see the attached test case to understand more. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (ZOOKEEPER-3053) add remove watches capabilities to the c cli
[ https://issues.apache.org/jira/browse/ZOOKEEPER-3053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Penzes updated ZOOKEEPER-3053: Labels: newbie remove_watches (was: newbie) > add remove watches capabilities to the c cli > > > Key: ZOOKEEPER-3053 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3053 > Project: ZooKeeper > Issue Type: Bug > Components: c client, tests >Affects Versions: 3.6.0, 3.5.5 >Reporter: Patrick Hunt >Priority: Major > Labels: newbie, remove_watches > > It would be good to be able to exercise the remove watches functionality from > the c client cli. Mostly for testing purposes. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (ZOOKEEPER-3212) Fix website with adding doap.rdf back
Tamas Penzes created ZOOKEEPER-3212: --- Summary: Fix website with adding doap.rdf back Key: ZOOKEEPER-3212 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3212 Project: ZooKeeper Issue Type: Bug Components: other Reporter: Tamas Penzes Assignee: Tamas Penzes During the website migration the doap.rdf file has been forgotten. Must be put back to its place. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (ZOOKEEPER-925) Consider maven site generation to replace our forrest site and documentation generation
[ https://issues.apache.org/jira/browse/ZOOKEEPER-925?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Penzes resolved ZOOKEEPER-925. Resolution: Fixed > Consider maven site generation to replace our forrest site and documentation > generation > --- > > Key: ZOOKEEPER-925 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-925 > Project: ZooKeeper > Issue Type: Task > Components: documentation >Affects Versions: 3.5.4, 3.6.0, 3.4.13 >Reporter: Patrick Hunt >Assignee: Tamas Penzes >Priority: Major > Fix For: 3.6.0, 3.5.5, 3.4.14 > > Attachments: CMS_w_RST.patch, ZOOKEEPER-925.patch, ZOOKEEPER-925.patch > > > See WHIRR-19 for some background. > In whirr we looked at a number of site/doc generation facilities. In the end > Maven site generation plugin turned out to be by far the best option. You can > see our nascent site here (no attempt at styling,etc so far): > http://incubator.apache.org/whirr/ > In particular take a look at the quick start: > http://incubator.apache.org/whirr/quick-start-guide.html > which was generated from > http://svn.apache.org/repos/asf/incubator/whirr/trunk/src/site/confluence/quick-start-guide.confluence > notice this was standard wiki markup (confluence wiki markup, same as > available from apache) > You can read more about mvn site plugin here: > http://maven.apache.org/guides/mini/guide-site.html > Notice that other formats are available, not just confluence markup, also > note that you can use different markup formats if you like in the same site > (although probably not a great idea, but in some cases might be handy, for > example whirr uses the confluence wiki, so we can pretty much copy/paste > source docs from wiki to our site (svn) if we like) > Re maven vs our current ant based build. It's probably a good idea for us to > move the build to maven at some point. We could initially move just the doc > generation, and then incrementally move functionality from build.xml to mvn > over a longer time period. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ZOOKEEPER-925) Consider maven site generation to replace our forrest site and documentation generation
[ https://issues.apache.org/jira/browse/ZOOKEEPER-925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16712711#comment-16712711 ] Tamas Penzes commented on ZOOKEEPER-925: All subtasks done, closing. > Consider maven site generation to replace our forrest site and documentation > generation > --- > > Key: ZOOKEEPER-925 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-925 > Project: ZooKeeper > Issue Type: Task > Components: documentation >Affects Versions: 3.5.4, 3.6.0, 3.4.13 >Reporter: Patrick Hunt >Assignee: Tamas Penzes >Priority: Major > Fix For: 3.6.0, 3.5.5, 3.4.14 > > Attachments: CMS_w_RST.patch, ZOOKEEPER-925.patch, ZOOKEEPER-925.patch > > > See WHIRR-19 for some background. > In whirr we looked at a number of site/doc generation facilities. In the end > Maven site generation plugin turned out to be by far the best option. You can > see our nascent site here (no attempt at styling,etc so far): > http://incubator.apache.org/whirr/ > In particular take a look at the quick start: > http://incubator.apache.org/whirr/quick-start-guide.html > which was generated from > http://svn.apache.org/repos/asf/incubator/whirr/trunk/src/site/confluence/quick-start-guide.confluence > notice this was standard wiki markup (confluence wiki markup, same as > available from apache) > You can read more about mvn site plugin here: > http://maven.apache.org/guides/mini/guide-site.html > Notice that other formats are available, not just confluence markup, also > note that you can use different markup formats if you like in the same site > (although probably not a great idea, but in some cases might be handy, for > example whirr uses the confluence wiki, so we can pretty much copy/paste > source docs from wiki to our site (svn) if we like) > Re maven vs our current ant based build. It's probably a good idea for us to > move the build to maven at some point. We could initially move just the doc > generation, and then incrementally move functionality from build.xml to mvn > over a longer time period. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (ZOOKEEPER-3029) Create pom.xml for jute and server
[
https://issues.apache.org/jira/browse/ZOOKEEPER-3029?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Penzes updated ZOOKEEPER-3029:
Priority: Blocker (was: Major)
> Create pom.xml for jute and server
> --
>
> Key: ZOOKEEPER-3029
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3029
> Project: ZooKeeper
> Issue Type: Sub-task
> Components: build, scripts
>Affects Versions: 3.6.0
>Reporter: Norbert Kalmar
>Assignee: Norbert Kalmar
>Priority: Blocker
>
> After the directory structures has been created, it is time to create the pom
> files for all the modules, and create the build hierarchy.
> At first, ant should remain in place until we are sure maven works fine.
> jute and server should be priority first. docs is handled in a different
> jira, as it is also being migrated. Recipes and contrib will remain for last.
> The different modules will get their maven structure:
> {noformat}
> zookeeper-[something]
> | -src
> || -main
> ||| -java
> ||| \org...
> ||\resources
> || -test (unit tests only)
> ||| -java
> ||| \org...
> ||\ resources
> || - it (integration tests)
> |\pom.xml
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (ZOOKEEPER-3171) Create pom.xml for recipes and contrib
[
https://issues.apache.org/jira/browse/ZOOKEEPER-3171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Penzes updated ZOOKEEPER-3171:
Fix Version/s: 3.4.14
3.5.5
3.6.0
> Create pom.xml for recipes and contrib
> --
>
> Key: ZOOKEEPER-3171
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3171
> Project: ZooKeeper
> Issue Type: Sub-task
> Components: build, scripts
>Affects Versions: 3.5.4, 3.6.0, 3.4.13
>Reporter: Norbert Kalmar
>Assignee: Norbert Kalmar
>Priority: Blocker
> Fix For: 3.6.0, 3.5.5, 3.4.14
>
>
> After the directory structures has been created, it is time to create the pom
> files for all the modules, and create the build hierarchy.
> At first, ant should remain in place until we are sure maven works fine.
> After maven build is stable for jute, server, client and common recipes and
> contrib should be finished as well.
> The different modules will get their maven structure:
> {noformat}
> zookeeper-[something]
> | -src
> || -main
> ||| -java
> ||| \org...
> ||\resources
> || -test (unit tests only)
> ||| -java
> ||| \org...
> ||\ resources
> || - it (integration tests)
> |\pom.xml
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (ZOOKEEPER-3171) Create pom.xml for recipes and contrib
[
https://issues.apache.org/jira/browse/ZOOKEEPER-3171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Penzes updated ZOOKEEPER-3171:
Priority: Blocker (was: Major)
> Create pom.xml for recipes and contrib
> --
>
> Key: ZOOKEEPER-3171
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3171
> Project: ZooKeeper
> Issue Type: Sub-task
> Components: build, scripts
>Affects Versions: 3.5.4, 3.6.0, 3.4.13
>Reporter: Norbert Kalmar
>Assignee: Norbert Kalmar
>Priority: Blocker
> Fix For: 3.6.0, 3.5.5, 3.4.14
>
>
> After the directory structures has been created, it is time to create the pom
> files for all the modules, and create the build hierarchy.
> At first, ant should remain in place until we are sure maven works fine.
> After maven build is stable for jute, server, client and common recipes and
> contrib should be finished as well.
> The different modules will get their maven structure:
> {noformat}
> zookeeper-[something]
> | -src
> || -main
> ||| -java
> ||| \org...
> ||\resources
> || -test (unit tests only)
> ||| -java
> ||| \org...
> ||\ resources
> || - it (integration tests)
> |\pom.xml
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (ZOOKEEPER-3171) Create pom.xml for recipes and contrib
[
https://issues.apache.org/jira/browse/ZOOKEEPER-3171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Penzes updated ZOOKEEPER-3171:
Affects Version/s: 3.5.4
3.4.13
> Create pom.xml for recipes and contrib
> --
>
> Key: ZOOKEEPER-3171
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3171
> Project: ZooKeeper
> Issue Type: Sub-task
> Components: build, scripts
>Affects Versions: 3.5.4, 3.6.0, 3.4.13
>Reporter: Norbert Kalmar
>Assignee: Norbert Kalmar
>Priority: Major
> Fix For: 3.6.0, 3.5.5, 3.4.14
>
>
> After the directory structures has been created, it is time to create the pom
> files for all the modules, and create the build hierarchy.
> At first, ant should remain in place until we are sure maven works fine.
> After maven build is stable for jute, server, client and common recipes and
> contrib should be finished as well.
> The different modules will get their maven structure:
> {noformat}
> zookeeper-[something]
> | -src
> || -main
> ||| -java
> ||| \org...
> ||\resources
> || -test (unit tests only)
> ||| -java
> ||| \org...
> ||\ resources
> || - it (integration tests)
> |\pom.xml
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (ZOOKEEPER-3029) Create pom.xml for jute and server
[
https://issues.apache.org/jira/browse/ZOOKEEPER-3029?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Penzes updated ZOOKEEPER-3029:
Fix Version/s: 3.4.14
3.5.5
3.6.0
> Create pom.xml for jute and server
> --
>
> Key: ZOOKEEPER-3029
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3029
> Project: ZooKeeper
> Issue Type: Sub-task
> Components: build, scripts
>Affects Versions: 3.5.4, 3.6.0, 3.4.13
>Reporter: Norbert Kalmar
>Assignee: Norbert Kalmar
>Priority: Blocker
> Fix For: 3.6.0, 3.5.5, 3.4.14
>
>
> After the directory structures has been created, it is time to create the pom
> files for all the modules, and create the build hierarchy.
> At first, ant should remain in place until we are sure maven works fine.
> jute and server should be priority first. docs is handled in a different
> jira, as it is also being migrated. Recipes and contrib will remain for last.
> The different modules will get their maven structure:
> {noformat}
> zookeeper-[something]
> | -src
> || -main
> ||| -java
> ||| \org...
> ||\resources
> || -test (unit tests only)
> ||| -java
> ||| \org...
> ||\ resources
> || - it (integration tests)
> |\pom.xml
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (ZOOKEEPER-3028) Create assembly in pom.xml
[ https://issues.apache.org/jira/browse/ZOOKEEPER-3028?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Penzes updated ZOOKEEPER-3028: Priority: Blocker (was: Major) > Create assembly in pom.xml > -- > > Key: ZOOKEEPER-3028 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3028 > Project: ZooKeeper > Issue Type: Sub-task > Components: build, scripts >Affects Versions: 3.5.4, 3.6.0, 3.4.13 >Reporter: Norbert Kalmar >Assignee: Tamas Penzes >Priority: Blocker > Fix For: 3.6.0, 3.5.5, 3.4.14 > > > After building the modules, it should be still packaged in a single tar. An > assembly plugin would be a relatively easy way to do this. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (ZOOKEEPER-3028) Create assembly in pom.xml
[ https://issues.apache.org/jira/browse/ZOOKEEPER-3028?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Penzes updated ZOOKEEPER-3028: Fix Version/s: 3.4.14 3.5.5 3.6.0 > Create assembly in pom.xml > -- > > Key: ZOOKEEPER-3028 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3028 > Project: ZooKeeper > Issue Type: Sub-task > Components: build, scripts >Affects Versions: 3.5.4, 3.6.0, 3.4.13 >Reporter: Norbert Kalmar >Assignee: Tamas Penzes >Priority: Major > Fix For: 3.6.0, 3.5.5, 3.4.14 > > > After building the modules, it should be still packaged in a single tar. An > assembly plugin would be a relatively easy way to do this. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (ZOOKEEPER-3029) Create pom.xml for jute and server
[
https://issues.apache.org/jira/browse/ZOOKEEPER-3029?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Penzes updated ZOOKEEPER-3029:
Affects Version/s: 3.5.4
3.4.13
> Create pom.xml for jute and server
> --
>
> Key: ZOOKEEPER-3029
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3029
> Project: ZooKeeper
> Issue Type: Sub-task
> Components: build, scripts
>Affects Versions: 3.5.4, 3.6.0, 3.4.13
>Reporter: Norbert Kalmar
>Assignee: Norbert Kalmar
>Priority: Blocker
> Fix For: 3.6.0, 3.5.5, 3.4.14
>
>
> After the directory structures has been created, it is time to create the pom
> files for all the modules, and create the build hierarchy.
> At first, ant should remain in place until we are sure maven works fine.
> jute and server should be priority first. docs is handled in a different
> jira, as it is also being migrated. Recipes and contrib will remain for last.
> The different modules will get their maven structure:
> {noformat}
> zookeeper-[something]
> | -src
> || -main
> ||| -java
> ||| \org...
> ||\resources
> || -test (unit tests only)
> ||| -java
> ||| \org...
> ||\ resources
> || - it (integration tests)
> |\pom.xml
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (ZOOKEEPER-3028) Create assembly in pom.xml
[ https://issues.apache.org/jira/browse/ZOOKEEPER-3028?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Penzes updated ZOOKEEPER-3028: Affects Version/s: 3.5.4 3.4.13 > Create assembly in pom.xml > -- > > Key: ZOOKEEPER-3028 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3028 > Project: ZooKeeper > Issue Type: Sub-task > Components: build, scripts >Affects Versions: 3.5.4, 3.6.0, 3.4.13 >Reporter: Norbert Kalmar >Assignee: Tamas Penzes >Priority: Major > Fix For: 3.6.0, 3.5.5, 3.4.14 > > > After building the modules, it should be still packaged in a single tar. An > assembly plugin would be a relatively easy way to do this. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (ZOOKEEPER-925) Consider maven site generation to replace our forrest site and documentation generation
[ https://issues.apache.org/jira/browse/ZOOKEEPER-925?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Penzes updated ZOOKEEPER-925: --- Priority: Critical (was: Blocker) > Consider maven site generation to replace our forrest site and documentation > generation > --- > > Key: ZOOKEEPER-925 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-925 > Project: ZooKeeper > Issue Type: Task > Components: documentation >Affects Versions: 3.5.4, 3.6.0, 3.4.13 >Reporter: Patrick Hunt >Assignee: Tamas Penzes >Priority: Critical > Fix For: 3.6.0, 3.5.5, 3.4.14 > > Attachments: CMS_w_RST.patch, ZOOKEEPER-925.patch, ZOOKEEPER-925.patch > > > See WHIRR-19 for some background. > In whirr we looked at a number of site/doc generation facilities. In the end > Maven site generation plugin turned out to be by far the best option. You can > see our nascent site here (no attempt at styling,etc so far): > http://incubator.apache.org/whirr/ > In particular take a look at the quick start: > http://incubator.apache.org/whirr/quick-start-guide.html > which was generated from > http://svn.apache.org/repos/asf/incubator/whirr/trunk/src/site/confluence/quick-start-guide.confluence > notice this was standard wiki markup (confluence wiki markup, same as > available from apache) > You can read more about mvn site plugin here: > http://maven.apache.org/guides/mini/guide-site.html > Notice that other formats are available, not just confluence markup, also > note that you can use different markup formats if you like in the same site > (although probably not a great idea, but in some cases might be handy, for > example whirr uses the confluence wiki, so we can pretty much copy/paste > source docs from wiki to our site (svn) if we like) > Re maven vs our current ant based build. It's probably a good idea for us to > move the build to maven at some point. We could initially move just the doc > generation, and then incrementally move functionality from build.xml to mvn > over a longer time period. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (ZOOKEEPER-925) Consider maven site generation to replace our forrest site and documentation generation
[ https://issues.apache.org/jira/browse/ZOOKEEPER-925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16682219#comment-16682219 ] Tamas Penzes commented on ZOOKEEPER-925: Since the documentation changes are done this is not a blocker anymore. Website changes are version independent. > Consider maven site generation to replace our forrest site and documentation > generation > --- > > Key: ZOOKEEPER-925 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-925 > Project: ZooKeeper > Issue Type: Task > Components: documentation >Affects Versions: 3.5.4, 3.6.0, 3.4.13 >Reporter: Patrick Hunt >Assignee: Tamas Penzes >Priority: Major > Fix For: 3.6.0, 3.5.5, 3.4.14 > > Attachments: CMS_w_RST.patch, ZOOKEEPER-925.patch, ZOOKEEPER-925.patch > > > See WHIRR-19 for some background. > In whirr we looked at a number of site/doc generation facilities. In the end > Maven site generation plugin turned out to be by far the best option. You can > see our nascent site here (no attempt at styling,etc so far): > http://incubator.apache.org/whirr/ > In particular take a look at the quick start: > http://incubator.apache.org/whirr/quick-start-guide.html > which was generated from > http://svn.apache.org/repos/asf/incubator/whirr/trunk/src/site/confluence/quick-start-guide.confluence > notice this was standard wiki markup (confluence wiki markup, same as > available from apache) > You can read more about mvn site plugin here: > http://maven.apache.org/guides/mini/guide-site.html > Notice that other formats are available, not just confluence markup, also > note that you can use different markup formats if you like in the same site > (although probably not a great idea, but in some cases might be handy, for > example whirr uses the confluence wiki, so we can pretty much copy/paste > source docs from wiki to our site (svn) if we like) > Re maven vs our current ant based build. It's probably a good idea for us to > move the build to maven at some point. We could initially move just the doc > generation, and then incrementally move functionality from build.xml to mvn > over a longer time period. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (ZOOKEEPER-925) Consider maven site generation to replace our forrest site and documentation generation
[ https://issues.apache.org/jira/browse/ZOOKEEPER-925?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Penzes updated ZOOKEEPER-925: --- Priority: Major (was: Critical) > Consider maven site generation to replace our forrest site and documentation > generation > --- > > Key: ZOOKEEPER-925 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-925 > Project: ZooKeeper > Issue Type: Task > Components: documentation >Affects Versions: 3.5.4, 3.6.0, 3.4.13 >Reporter: Patrick Hunt >Assignee: Tamas Penzes >Priority: Major > Fix For: 3.6.0, 3.5.5, 3.4.14 > > Attachments: CMS_w_RST.patch, ZOOKEEPER-925.patch, ZOOKEEPER-925.patch > > > See WHIRR-19 for some background. > In whirr we looked at a number of site/doc generation facilities. In the end > Maven site generation plugin turned out to be by far the best option. You can > see our nascent site here (no attempt at styling,etc so far): > http://incubator.apache.org/whirr/ > In particular take a look at the quick start: > http://incubator.apache.org/whirr/quick-start-guide.html > which was generated from > http://svn.apache.org/repos/asf/incubator/whirr/trunk/src/site/confluence/quick-start-guide.confluence > notice this was standard wiki markup (confluence wiki markup, same as > available from apache) > You can read more about mvn site plugin here: > http://maven.apache.org/guides/mini/guide-site.html > Notice that other formats are available, not just confluence markup, also > note that you can use different markup formats if you like in the same site > (although probably not a great idea, but in some cases might be handy, for > example whirr uses the confluence wiki, so we can pretty much copy/paste > source docs from wiki to our site (svn) if we like) > Re maven vs our current ant based build. It's probably a good idea for us to > move the build to maven at some point. We could initially move just the doc > generation, and then incrementally move functionality from build.xml to mvn > over a longer time period. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (ZOOKEEPER-3184) Use the same method to generate website as documentation
Tamas Penzes created ZOOKEEPER-3184: --- Summary: Use the same method to generate website as documentation Key: ZOOKEEPER-3184 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3184 Project: ZooKeeper Issue Type: Sub-task Reporter: Tamas Penzes Assignee: Tamas Penzes We should use the same method to generate website as we do the documentation. This way we would get rid of Jekyll and would not need to install anything on the build machines. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (ZOOKEEPER-2778) Potential server deadlock between follower sync with leader and follower receiving external connection requests.
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2778?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Penzes updated ZOOKEEPER-2778:
Fix Version/s: 3.5.5
3.6.0
> Potential server deadlock between follower sync with leader and follower
> receiving external connection requests.
>
>
> Key: ZOOKEEPER-2778
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2778
> Project: ZooKeeper
> Issue Type: Bug
> Components: quorum
>Affects Versions: 3.5.3
>Reporter: Michael Han
>Assignee: maoling
>Priority: Critical
> Fix For: 3.6.0, 3.5.5
>
>
> It's possible to have a deadlock during recovery phase.
> Found this issue by analyzing thread dumps of "flaky" ReconfigRecoveryTest
> [1]. . Here is a sample thread dump that illustrates the state of the
> execution:
> {noformat}
> [junit] java.lang.Thread.State: BLOCKED
> [junit] at
> org.apache.zookeeper.server.quorum.QuorumPeer.getElectionAddress(QuorumPeer.java:686)
> [junit] at
> org.apache.zookeeper.server.quorum.QuorumCnxManager.initiateConnection(QuorumCnxManager.java:265)
> [junit] at
> org.apache.zookeeper.server.quorum.QuorumCnxManager.connectOne(QuorumCnxManager.java:445)
> [junit] at
> org.apache.zookeeper.server.quorum.QuorumCnxManager.receiveConnection(QuorumCnxManager.java:369)
> [junit] at
> org.apache.zookeeper.server.quorum.QuorumCnxManager$Listener.run(QuorumCnxManager.java:642)
> [junit]
> [junit] java.lang.Thread.State: BLOCKED
> [junit] at
> org.apache.zookeeper.server.quorum.QuorumCnxManager.connectOne(QuorumCnxManager.java:472)
> [junit] at
> org.apache.zookeeper.server.quorum.QuorumPeer.connectNewPeers(QuorumPeer.java:1438)
> [junit] at
> org.apache.zookeeper.server.quorum.QuorumPeer.setLastSeenQuorumVerifier(QuorumPeer.java:1471)
> [junit] at
> org.apache.zookeeper.server.quorum.Learner.syncWithLeader(Learner.java:520)
> [junit] at
> org.apache.zookeeper.server.quorum.Follower.followLeader(Follower.java:88)
> [junit] at
> org.apache.zookeeper.server.quorum.QuorumPeer.run(QuorumPeer.java:1133)
> {noformat}
> The dead lock happens between the quorum peer thread which running the
> follower that doing sync with leader work, and the listener of the qcm of the
> same quorum peer that doing the receiving connection work. Basically to
> finish sync with leader, the follower needs to synchronize on both QV_LOCK
> and the qmc object it owns; while in the receiver thread to finish setup an
> incoming connection the thread needs to synchronize on both the qcm object
> the quorum peer owns, and the same QV_LOCK. It's easy to see the problem here
> is the order of acquiring two locks are different, thus depends on timing /
> actual execution order, two threads might end up acquiring one lock while
> holding another.
> [1]
> org.apache.zookeeper.server.quorum.ReconfigRecoveryTest.testCurrentServersAreObserversInNextConfig
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (ZOOKEEPER-2778) Potential server deadlock between follower sync with leader and follower receiving external connection requests.
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2778?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Penzes updated ZOOKEEPER-2778:
Priority: Blocker (was: Critical)
> Potential server deadlock between follower sync with leader and follower
> receiving external connection requests.
>
>
> Key: ZOOKEEPER-2778
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2778
> Project: ZooKeeper
> Issue Type: Bug
> Components: quorum
>Affects Versions: 3.5.3
>Reporter: Michael Han
>Assignee: maoling
>Priority: Blocker
> Fix For: 3.6.0, 3.5.5
>
>
> It's possible to have a deadlock during recovery phase.
> Found this issue by analyzing thread dumps of "flaky" ReconfigRecoveryTest
> [1]. . Here is a sample thread dump that illustrates the state of the
> execution:
> {noformat}
> [junit] java.lang.Thread.State: BLOCKED
> [junit] at
> org.apache.zookeeper.server.quorum.QuorumPeer.getElectionAddress(QuorumPeer.java:686)
> [junit] at
> org.apache.zookeeper.server.quorum.QuorumCnxManager.initiateConnection(QuorumCnxManager.java:265)
> [junit] at
> org.apache.zookeeper.server.quorum.QuorumCnxManager.connectOne(QuorumCnxManager.java:445)
> [junit] at
> org.apache.zookeeper.server.quorum.QuorumCnxManager.receiveConnection(QuorumCnxManager.java:369)
> [junit] at
> org.apache.zookeeper.server.quorum.QuorumCnxManager$Listener.run(QuorumCnxManager.java:642)
> [junit]
> [junit] java.lang.Thread.State: BLOCKED
> [junit] at
> org.apache.zookeeper.server.quorum.QuorumCnxManager.connectOne(QuorumCnxManager.java:472)
> [junit] at
> org.apache.zookeeper.server.quorum.QuorumPeer.connectNewPeers(QuorumPeer.java:1438)
> [junit] at
> org.apache.zookeeper.server.quorum.QuorumPeer.setLastSeenQuorumVerifier(QuorumPeer.java:1471)
> [junit] at
> org.apache.zookeeper.server.quorum.Learner.syncWithLeader(Learner.java:520)
> [junit] at
> org.apache.zookeeper.server.quorum.Follower.followLeader(Follower.java:88)
> [junit] at
> org.apache.zookeeper.server.quorum.QuorumPeer.run(QuorumPeer.java:1133)
> {noformat}
> The dead lock happens between the quorum peer thread which running the
> follower that doing sync with leader work, and the listener of the qcm of the
> same quorum peer that doing the receiving connection work. Basically to
> finish sync with leader, the follower needs to synchronize on both QV_LOCK
> and the qmc object it owns; while in the receiver thread to finish setup an
> incoming connection the thread needs to synchronize on both the qcm object
> the quorum peer owns, and the same QV_LOCK. It's easy to see the problem here
> is the order of acquiring two locks are different, thus depends on timing /
> actual execution order, two threads might end up acquiring one lock while
> holding another.
> [1]
> org.apache.zookeeper.server.quorum.ReconfigRecoveryTest.testCurrentServersAreObserversInNextConfig
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (ZOOKEEPER-2051) Creating ephemeral znodes from within a transaction fail with local sessions
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2051?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Penzes updated ZOOKEEPER-2051:
Priority: Major (was: Critical)
> Creating ephemeral znodes from within a transaction fail with local sessions
>
>
> Key: ZOOKEEPER-2051
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2051
> Project: ZooKeeper
> Issue Type: Bug
> Components: server
>Affects Versions: 3.5.0
>Reporter: Raul Gutierrez Segales
>Assignee: Raul Gutierrez Segales
>Priority: Major
> Fix For: 3.6.0
>
>
> With local sessions enabled, the premise is that as soon as you try to create
> an ephemeral znode your session will be upgraded to global. The problem is
> that the session upgrade logic doesn't intercept transactions. So creating an
> ephemeral znode from within a transaction fails with SessionExpired.
> A small example with Kazoo:
> {noformat}
> from kazoo.client import KazooClient
> k = KazooClient("localhost:2181")
> k.start()
> t = k.transaction()
> t.create("/hello_", "", ephemeral=True)
> t.commit()
> [kazoo.exceptions.SessionExpiredError((), {})]
> {noformat}
> A workaround, for now, is to create an ephemeral before your transaction
> which forces your session to be upgraded.
> Possible solutions could be:
> * extending zookeeper_init() so that you can request global=True
> * and/or, providing an upgradeSession() API
> Thoughts?
> cc: [~thawan], [~phunt], [~fpj]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (ZOOKEEPER-2051) Creating ephemeral znodes from within a transaction fail with local sessions
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2051?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Penzes updated ZOOKEEPER-2051:
Fix Version/s: (was: 3.5.5)
> Creating ephemeral znodes from within a transaction fail with local sessions
>
>
> Key: ZOOKEEPER-2051
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2051
> Project: ZooKeeper
> Issue Type: Bug
> Components: server
>Affects Versions: 3.5.0
>Reporter: Raul Gutierrez Segales
>Assignee: Raul Gutierrez Segales
>Priority: Major
> Fix For: 3.6.0
>
>
> With local sessions enabled, the premise is that as soon as you try to create
> an ephemeral znode your session will be upgraded to global. The problem is
> that the session upgrade logic doesn't intercept transactions. So creating an
> ephemeral znode from within a transaction fails with SessionExpired.
> A small example with Kazoo:
> {noformat}
> from kazoo.client import KazooClient
> k = KazooClient("localhost:2181")
> k.start()
> t = k.transaction()
> t.create("/hello_", "", ephemeral=True)
> t.commit()
> [kazoo.exceptions.SessionExpiredError((), {})]
> {noformat}
> A workaround, for now, is to create an ephemeral before your transaction
> which forces your session to be upgraded.
> Possible solutions could be:
> * extending zookeeper_init() so that you can request global=True
> * and/or, providing an upgradeSession() API
> Thoughts?
> cc: [~thawan], [~phunt], [~fpj]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (ZOOKEEPER-1998) C library calls getaddrinfo unconditionally from zookeeper_interest
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Penzes updated ZOOKEEPER-1998: Fix Version/s: (was: 3.5.5) > C library calls getaddrinfo unconditionally from zookeeper_interest > --- > > Key: ZOOKEEPER-1998 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1998 > Project: ZooKeeper > Issue Type: Bug > Components: c client >Affects Versions: 3.5.0 >Reporter: Raul Gutierrez Segales >Assignee: Raul Gutierrez Segales >Priority: Major > Fix For: 3.6.0 > > > (commented this on ZOOKEEPER-338) > I've just noticed that we call getaddrinfo from zookeeper_interest... on > every call. So from zookeeper_interest we always call update_addrs: > https://github.com/apache/zookeeper/blob/trunk/src/c/src/zookeeper.c#L2082 > which in turns unconditionally calls resolve_hosts: > https://github.com/apache/zookeeper/blob/trunk/src/c/src/zookeeper.c#L787 > which does the unconditional calls to getaddrinfo: > https://github.com/apache/zookeeper/blob/trunk/src/c/src/zookeeper.c#L648 > We should fix this since it'll make 3.5.0 slower for people relying on DNS. I > think this is happened as part of ZOOKEEPER-107 in which the list of servers > can be updated. > cc: [~shralex], [~phunt], [~fpj] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (ZOOKEEPER-1998) C library calls getaddrinfo unconditionally from zookeeper_interest
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Penzes updated ZOOKEEPER-1998: Priority: Major (was: Critical) > C library calls getaddrinfo unconditionally from zookeeper_interest > --- > > Key: ZOOKEEPER-1998 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1998 > Project: ZooKeeper > Issue Type: Bug > Components: c client >Affects Versions: 3.5.0 >Reporter: Raul Gutierrez Segales >Assignee: Raul Gutierrez Segales >Priority: Major > Fix For: 3.6.0 > > > (commented this on ZOOKEEPER-338) > I've just noticed that we call getaddrinfo from zookeeper_interest... on > every call. So from zookeeper_interest we always call update_addrs: > https://github.com/apache/zookeeper/blob/trunk/src/c/src/zookeeper.c#L2082 > which in turns unconditionally calls resolve_hosts: > https://github.com/apache/zookeeper/blob/trunk/src/c/src/zookeeper.c#L787 > which does the unconditional calls to getaddrinfo: > https://github.com/apache/zookeeper/blob/trunk/src/c/src/zookeeper.c#L648 > We should fix this since it'll make 3.5.0 slower for people relying on DNS. I > think this is happened as part of ZOOKEEPER-107 in which the list of servers > can be updated. > cc: [~shralex], [~phunt], [~fpj] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (ZOOKEEPER-1985) Memory leak in C client
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1985?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Penzes updated ZOOKEEPER-1985: Priority: Major (was: Critical) > Memory leak in C client > --- > > Key: ZOOKEEPER-1985 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1985 > Project: ZooKeeper > Issue Type: Bug > Components: c client >Affects Versions: 3.4.6 >Reporter: desmondhe >Assignee: desmondhe >Priority: Major > Fix For: 3.6.0, 3.5.5 > > Attachments: ZOOKEEPER-1985.patch > > > in the file zookeeper.c, most function call of "close_buffer_oarchive(, > 0)" shoud been instead by > close_buffer_oarchive(, rc < 0 ? 1 : 0); -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (ZOOKEEPER-1777) Missing ephemeral nodes in one of the members of the ensemble
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1777?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Penzes updated ZOOKEEPER-1777: Fix Version/s: (was: 3.5.5) > Missing ephemeral nodes in one of the members of the ensemble > - > > Key: ZOOKEEPER-1777 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1777 > Project: ZooKeeper > Issue Type: Bug > Components: quorum >Affects Versions: 3.4.5 > Environment: Linux, Java 1.7 >Reporter: Germán Blanco >Assignee: Germán Blanco >Priority: Critical > Fix For: 3.6.0 > > Attachments: ZOOKEEPER-1777-3.4.patch, ZOOKEEPER-1777.patch, > ZOOKEEPER-1777.patch, ZOOKEEPER-1777.tar.gz, logs_trunk.tar.gz, snaps.tar > > > In a 3-servers ensemble, one of the followers doesn't see part of the > ephemeral nodes that are present in the leader and the other follower. > The 8 missing nodes in "the follower that is not ok" were created in the end > of epoch 1, the ensemble is running in epoch 2. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (ZOOKEEPER-1777) Missing ephemeral nodes in one of the members of the ensemble
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1777?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Penzes updated ZOOKEEPER-1777: Priority: Major (was: Critical) > Missing ephemeral nodes in one of the members of the ensemble > - > > Key: ZOOKEEPER-1777 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1777 > Project: ZooKeeper > Issue Type: Bug > Components: quorum >Affects Versions: 3.4.5 > Environment: Linux, Java 1.7 >Reporter: Germán Blanco >Assignee: Germán Blanco >Priority: Major > Fix For: 3.6.0 > > Attachments: ZOOKEEPER-1777-3.4.patch, ZOOKEEPER-1777.patch, > ZOOKEEPER-1777.patch, ZOOKEEPER-1777.tar.gz, logs_trunk.tar.gz, snaps.tar > > > In a 3-servers ensemble, one of the followers doesn't see part of the > ephemeral nodes that are present in the leader and the other follower. > The 8 missing nodes in "the follower that is not ok" were created in the end > of epoch 1, the ensemble is running in epoch 2. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (ZOOKEEPER-1467) Server principal on client side is derived using hostname.
[
https://issues.apache.org/jira/browse/ZOOKEEPER-1467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Penzes updated ZOOKEEPER-1467:
Issue Type: Improvement (was: Bug)
> Server principal on client side is derived using hostname.
> --
>
> Key: ZOOKEEPER-1467
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1467
> Project: ZooKeeper
> Issue Type: Improvement
> Components: java client
>Affects Versions: 3.4.3, 3.4.4, 3.5.0
>Reporter: Laxman
>Assignee: Eugene Koontz
>Priority: Major
> Labels: Security, client, kerberos, sasl
> Fix For: 3.6.0
>
> Attachments: ZOOKEEPER-1467.patch, ZOOKEEPER-1467.patch
>
>
> Server principal on client side is derived using hostname.
> org.apache.zookeeper.ClientCnxn.SendThread.startConnect()
> {code}
>try {
> zooKeeperSaslClient = new
> ZooKeeperSaslClient("zookeeper/"+addr.getHostName());
> }
> {code}
> This may have problems when admin wanted some customized principals like
> zookeeper/cluste...@hadoop.com where clusterid is the cluster identifier but
> not the host name.
> IMO, server principal also should be configurable as hadoop is doing.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (ZOOKEEPER-1467) Server principal on client side is derived using hostname.
[
https://issues.apache.org/jira/browse/ZOOKEEPER-1467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Penzes updated ZOOKEEPER-1467:
Priority: Major (was: Critical)
> Server principal on client side is derived using hostname.
> --
>
> Key: ZOOKEEPER-1467
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1467
> Project: ZooKeeper
> Issue Type: Bug
> Components: java client
>Affects Versions: 3.4.3, 3.4.4, 3.5.0
>Reporter: Laxman
>Assignee: Eugene Koontz
>Priority: Major
> Labels: Security, client, kerberos, sasl
> Fix For: 3.6.0
>
> Attachments: ZOOKEEPER-1467.patch, ZOOKEEPER-1467.patch
>
>
> Server principal on client side is derived using hostname.
> org.apache.zookeeper.ClientCnxn.SendThread.startConnect()
> {code}
>try {
> zooKeeperSaslClient = new
> ZooKeeperSaslClient("zookeeper/"+addr.getHostName());
> }
> {code}
> This may have problems when admin wanted some customized principals like
> zookeeper/cluste...@hadoop.com where clusterid is the cluster identifier but
> not the host name.
> IMO, server principal also should be configurable as hadoop is doing.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (ZOOKEEPER-1467) Server principal on client side is derived using hostname.
[
https://issues.apache.org/jira/browse/ZOOKEEPER-1467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Penzes updated ZOOKEEPER-1467:
Fix Version/s: (was: 3.5.5)
> Server principal on client side is derived using hostname.
> --
>
> Key: ZOOKEEPER-1467
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1467
> Project: ZooKeeper
> Issue Type: Improvement
> Components: java client
>Affects Versions: 3.4.3, 3.4.4, 3.5.0
>Reporter: Laxman
>Assignee: Eugene Koontz
>Priority: Major
> Labels: Security, client, kerberos, sasl
> Fix For: 3.6.0
>
> Attachments: ZOOKEEPER-1467.patch, ZOOKEEPER-1467.patch
>
>
> Server principal on client side is derived using hostname.
> org.apache.zookeeper.ClientCnxn.SendThread.startConnect()
> {code}
>try {
> zooKeeperSaslClient = new
> ZooKeeperSaslClient("zookeeper/"+addr.getHostName());
> }
> {code}
> This may have problems when admin wanted some customized principals like
> zookeeper/cluste...@hadoop.com where clusterid is the cluster identifier but
> not the host name.
> IMO, server principal also should be configurable as hadoop is doing.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (ZOOKEEPER-1162) consistent handling of jute.maxbuffer when attempting to read large zk "directories"
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Penzes updated ZOOKEEPER-1162: Fix Version/s: (was: 3.5.5) > consistent handling of jute.maxbuffer when attempting to read large zk > "directories" > > > Key: ZOOKEEPER-1162 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1162 > Project: ZooKeeper > Issue Type: Improvement > Components: server >Affects Versions: 3.3.3 >Reporter: Jonathan Hsieh >Assignee: Michael Han >Priority: Major > Fix For: 3.6.0 > > > Recently we encountered a sitaution where a zk directory got sucessfully > populated with 250k elements. When our system attempted to read the znode > dir, it failed because the contents of the dir exceeded the default 1mb > jute.maxbuffer limit. There were a few odd things > 1) It seems odd that we could populate to be very large but could not read > the listing > 2) The workaround was bumping up jute.maxbuffer on the client side > Would it make more sense to have it reject adding new znodes if it exceeds > jute.maxbuffer? > Alternately, would it make sense to have zk dir listing ignore the > jute.maxbuffer setting? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (ZOOKEEPER-1162) consistent handling of jute.maxbuffer when attempting to read large zk "directories"
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Penzes updated ZOOKEEPER-1162: Priority: Major (was: Critical) > consistent handling of jute.maxbuffer when attempting to read large zk > "directories" > > > Key: ZOOKEEPER-1162 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1162 > Project: ZooKeeper > Issue Type: Improvement > Components: server >Affects Versions: 3.3.3 >Reporter: Jonathan Hsieh >Assignee: Michael Han >Priority: Major > Fix For: 3.6.0 > > > Recently we encountered a sitaution where a zk directory got sucessfully > populated with 250k elements. When our system attempted to read the znode > dir, it failed because the contents of the dir exceeded the default 1mb > jute.maxbuffer limit. There were a few odd things > 1) It seems odd that we could populate to be very large but could not read > the listing > 2) The workaround was bumping up jute.maxbuffer on the client side > Would it make more sense to have it reject adding new znodes if it exceeds > jute.maxbuffer? > Alternately, would it make sense to have zk dir listing ignore the > jute.maxbuffer setting? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (ZOOKEEPER-936) zkpython is leaking ACL_vector
[ https://issues.apache.org/jira/browse/ZOOKEEPER-936?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Penzes updated ZOOKEEPER-936: --- Priority: Major (was: Critical) > zkpython is leaking ACL_vector > -- > > Key: ZOOKEEPER-936 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-936 > Project: ZooKeeper > Issue Type: Bug > Components: contrib-bindings >Reporter: Gustavo Niemeyer >Priority: Major > Fix For: 3.6.0 > > > It looks like there are no calls to deallocate_ACL_vector() within > zookeeper.c in the zkpython binding, which means that (at least) the result > of zoo_get_acl() must be leaking. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (ZOOKEEPER-936) zkpython is leaking ACL_vector
[ https://issues.apache.org/jira/browse/ZOOKEEPER-936?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Penzes updated ZOOKEEPER-936: --- Fix Version/s: (was: 3.5.5) > zkpython is leaking ACL_vector > -- > > Key: ZOOKEEPER-936 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-936 > Project: ZooKeeper > Issue Type: Bug > Components: contrib-bindings >Reporter: Gustavo Niemeyer >Priority: Major > Fix For: 3.6.0 > > > It looks like there are no calls to deallocate_ACL_vector() within > zookeeper.c in the zkpython binding, which means that (at least) the result > of zoo_get_acl() must be leaking. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (ZOOKEEPER-900) FLE implementation should be improved to use non-blocking sockets
[ https://issues.apache.org/jira/browse/ZOOKEEPER-900?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Penzes updated ZOOKEEPER-900: --- Issue Type: Improvement (was: Bug) > FLE implementation should be improved to use non-blocking sockets > - > > Key: ZOOKEEPER-900 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-900 > Project: ZooKeeper > Issue Type: Improvement >Reporter: Vishal Kher >Assignee: Martin Kuchta >Priority: Major > Fix For: 3.6.0 > > Attachments: ZOOKEEPER-900-part2.patch, ZOOKEEPER-900.patch, > ZOOKEEPER-900.patch1, ZOOKEEPER-900.patch2 > > > From earlier email exchanges: > 1. Blocking connects and accepts: > a) The first problem is in manager.toSend(). This invokes connectOne(), which > does a blocking connect. While testing, I changed the code so that > connectOne() starts a new thread called AsyncConnct(). AsyncConnect.run() > does a socketChannel.connect(). After starting AsyncConnect, connectOne > starts a timer. connectOne continues with normal operations if the connection > is established before the timer expires, otherwise, when the timer expires it > interrupts AsyncConnect() thread and returns. In this way, I can have an > upper bound on the amount of time we need to wait for connect to succeed. Of > course, this was a quick fix for my testing. Ideally, we should use Selector > to do non-blocking connects/accepts. I am planning to do that later once we > at least have a quick fix for the problem and consensus from others for the > real fix (this problem is big blocker for us). Note that it is OK to do > blocking IO in SenderWorker and RecvWorker threads since they block IO to the > respective peer. > b) The blocking IO problem is not just restricted to connectOne(), but also > in receiveConnection(). The Listener thread calls receiveConnection() for > each incoming connection request. receiveConnection does blocking IO to get > peer's info (s.read(msgBuffer)). Worse, it invokes connectOne() back to the > peer that had sent the connection request. All of this is happening from the > Listener. In short, if a peer fails after initiating a connection, the > Listener thread won't be able to accept connections from other peers, because > it would be stuck in read() or connetOne(). Also the code has an inherent > cycle. initiateConnection() and receiveConnection() will have to be very > carefully synchronized otherwise, we could run into deadlocks. This code is > going to be difficult to maintain/modify. > Also see: https://issues.apache.org/jira/browse/ZOOKEEPER-822 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (ZOOKEEPER-900) FLE implementation should be improved to use non-blocking sockets
[ https://issues.apache.org/jira/browse/ZOOKEEPER-900?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Penzes updated ZOOKEEPER-900: --- Priority: Major (was: Critical) > FLE implementation should be improved to use non-blocking sockets > - > > Key: ZOOKEEPER-900 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-900 > Project: ZooKeeper > Issue Type: Bug >Reporter: Vishal Kher >Assignee: Martin Kuchta >Priority: Major > Fix For: 3.6.0 > > Attachments: ZOOKEEPER-900-part2.patch, ZOOKEEPER-900.patch, > ZOOKEEPER-900.patch1, ZOOKEEPER-900.patch2 > > > From earlier email exchanges: > 1. Blocking connects and accepts: > a) The first problem is in manager.toSend(). This invokes connectOne(), which > does a blocking connect. While testing, I changed the code so that > connectOne() starts a new thread called AsyncConnct(). AsyncConnect.run() > does a socketChannel.connect(). After starting AsyncConnect, connectOne > starts a timer. connectOne continues with normal operations if the connection > is established before the timer expires, otherwise, when the timer expires it > interrupts AsyncConnect() thread and returns. In this way, I can have an > upper bound on the amount of time we need to wait for connect to succeed. Of > course, this was a quick fix for my testing. Ideally, we should use Selector > to do non-blocking connects/accepts. I am planning to do that later once we > at least have a quick fix for the problem and consensus from others for the > real fix (this problem is big blocker for us). Note that it is OK to do > blocking IO in SenderWorker and RecvWorker threads since they block IO to the > respective peer. > b) The blocking IO problem is not just restricted to connectOne(), but also > in receiveConnection(). The Listener thread calls receiveConnection() for > each incoming connection request. receiveConnection does blocking IO to get > peer's info (s.read(msgBuffer)). Worse, it invokes connectOne() back to the > peer that had sent the connection request. All of this is happening from the > Listener. In short, if a peer fails after initiating a connection, the > Listener thread won't be able to accept connections from other peers, because > it would be stuck in read() or connetOne(). Also the code has an inherent > cycle. initiateConnection() and receiveConnection() will have to be very > carefully synchronized otherwise, we could run into deadlocks. This code is > going to be difficult to maintain/modify. > Also see: https://issues.apache.org/jira/browse/ZOOKEEPER-822 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (ZOOKEEPER-900) FLE implementation should be improved to use non-blocking sockets
[ https://issues.apache.org/jira/browse/ZOOKEEPER-900?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Penzes updated ZOOKEEPER-900: --- Fix Version/s: (was: 3.5.5) > FLE implementation should be improved to use non-blocking sockets > - > > Key: ZOOKEEPER-900 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-900 > Project: ZooKeeper > Issue Type: Bug >Reporter: Vishal Kher >Assignee: Martin Kuchta >Priority: Major > Fix For: 3.6.0 > > Attachments: ZOOKEEPER-900-part2.patch, ZOOKEEPER-900.patch, > ZOOKEEPER-900.patch1, ZOOKEEPER-900.patch2 > > > From earlier email exchanges: > 1. Blocking connects and accepts: > a) The first problem is in manager.toSend(). This invokes connectOne(), which > does a blocking connect. While testing, I changed the code so that > connectOne() starts a new thread called AsyncConnct(). AsyncConnect.run() > does a socketChannel.connect(). After starting AsyncConnect, connectOne > starts a timer. connectOne continues with normal operations if the connection > is established before the timer expires, otherwise, when the timer expires it > interrupts AsyncConnect() thread and returns. In this way, I can have an > upper bound on the amount of time we need to wait for connect to succeed. Of > course, this was a quick fix for my testing. Ideally, we should use Selector > to do non-blocking connects/accepts. I am planning to do that later once we > at least have a quick fix for the problem and consensus from others for the > real fix (this problem is big blocker for us). Note that it is OK to do > blocking IO in SenderWorker and RecvWorker threads since they block IO to the > respective peer. > b) The blocking IO problem is not just restricted to connectOne(), but also > in receiveConnection(). The Listener thread calls receiveConnection() for > each incoming connection request. receiveConnection does blocking IO to get > peer's info (s.read(msgBuffer)). Worse, it invokes connectOne() back to the > peer that had sent the connection request. All of this is happening from the > Listener. In short, if a peer fails after initiating a connection, the > Listener thread won't be able to accept connections from other peers, because > it would be stuck in read() or connetOne(). Also the code has an inherent > cycle. initiateConnection() and receiveConnection() will have to be very > carefully synchronized otherwise, we could run into deadlocks. This code is > going to be difficult to maintain/modify. > Also see: https://issues.apache.org/jira/browse/ZOOKEEPER-822 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (ZOOKEEPER-885) Zookeeper drops connections under moderate IO load
[
https://issues.apache.org/jira/browse/ZOOKEEPER-885?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Penzes updated ZOOKEEPER-885:
---
Priority: Major (was: Critical)
> Zookeeper drops connections under moderate IO load
> --
>
> Key: ZOOKEEPER-885
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-885
> Project: ZooKeeper
> Issue Type: Bug
> Components: server
>Affects Versions: 3.2.2, 3.3.1
> Environment: Debian (Lenny)
> 1Gb RAM
> swap disabled
> 100Mb heap for zookeeper
>Reporter: Alexandre Hardy
>Priority: Major
> Fix For: 3.6.0
>
> Attachments: WatcherTest.java, benchmark.csv, tracezklogs.tar.gz,
> tracezklogs.tar.gz, zklogs.tar.gz
>
>
> A zookeeper server under minimum load, with a number of clients watching
> exactly one node will fail to maintain the connection when the machine is
> subjected to moderate IO load.
> In a specific test example we had three zookeeper servers running on
> dedicated machines with 45 clients connected, watching exactly one node. The
> clients would disconnect after moderate load was added to each of the
> zookeeper servers with the command:
> {noformat}
> dd if=/dev/urandom of=/dev/mapper/nimbula-test
> {noformat}
> The {{dd}} command transferred data at a rate of about 4Mb/s.
> The same thing happens with
> {noformat}
> dd if=/dev/zero of=/dev/mapper/nimbula-test
> {noformat}
> It seems strange that such a moderate load should cause instability in the
> connection.
> Very few other processes were running, the machines were setup to test the
> connection instability we have experienced. Clients performed no other read
> or mutation operations.
> Although the documents state that minimal competing IO load should present on
> the zookeeper server, it seems reasonable that moderate IO should not cause
> problems in this case.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (ZOOKEEPER-885) Zookeeper drops connections under moderate IO load
[
https://issues.apache.org/jira/browse/ZOOKEEPER-885?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Penzes updated ZOOKEEPER-885:
---
Fix Version/s: (was: 3.5.5)
> Zookeeper drops connections under moderate IO load
> --
>
> Key: ZOOKEEPER-885
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-885
> Project: ZooKeeper
> Issue Type: Bug
> Components: server
>Affects Versions: 3.2.2, 3.3.1
> Environment: Debian (Lenny)
> 1Gb RAM
> swap disabled
> 100Mb heap for zookeeper
>Reporter: Alexandre Hardy
>Priority: Major
> Fix For: 3.6.0
>
> Attachments: WatcherTest.java, benchmark.csv, tracezklogs.tar.gz,
> tracezklogs.tar.gz, zklogs.tar.gz
>
>
> A zookeeper server under minimum load, with a number of clients watching
> exactly one node will fail to maintain the connection when the machine is
> subjected to moderate IO load.
> In a specific test example we had three zookeeper servers running on
> dedicated machines with 45 clients connected, watching exactly one node. The
> clients would disconnect after moderate load was added to each of the
> zookeeper servers with the command:
> {noformat}
> dd if=/dev/urandom of=/dev/mapper/nimbula-test
> {noformat}
> The {{dd}} command transferred data at a rate of about 4Mb/s.
> The same thing happens with
> {noformat}
> dd if=/dev/zero of=/dev/mapper/nimbula-test
> {noformat}
> It seems strange that such a moderate load should cause instability in the
> connection.
> Very few other processes were running, the machines were setup to test the
> connection instability we have experienced. Clients performed no other read
> or mutation operations.
> Although the documents state that minimal competing IO load should present on
> the zookeeper server, it seems reasonable that moderate IO should not cause
> problems in this case.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (ZOOKEEPER-2159) Pluggable SASL Authentication
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Penzes updated ZOOKEEPER-2159: Priority: Major (was: Blocker) > Pluggable SASL Authentication > - > > Key: ZOOKEEPER-2159 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2159 > Project: ZooKeeper > Issue Type: Improvement > Components: java client, server >Reporter: Yuliya Feldman >Assignee: Yuliya Feldman >Priority: Major > Fix For: 3.6.0, 3.5.5 > > Attachments: PluggableZookeeperAuthentication (1).pdf, > PluggableZookeeperAuthentication.pdf > > > Today SASLAuthenticationProvider is used for all SASL based authentications > which creates some "if/else" statements in ZookeeperSaslClient and > ZookeeperSaslServer code with just Kerberos and Digest. > We want to use yet another different SASL based authentication and adding one > more "if/else" with some code specific just to that new way does not make > much sense. > Proposal is to allow to plug custom SASL Authentication mechanism(s) without > further changes in Zookeeper code. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (ZOOKEEPER-1549) Data inconsistency when follower is receiving a DIFF with a dirty snapshot
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Penzes updated ZOOKEEPER-1549: Priority: Major (was: Blocker) > Data inconsistency when follower is receiving a DIFF with a dirty snapshot > -- > > Key: ZOOKEEPER-1549 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1549 > Project: ZooKeeper > Issue Type: Bug > Components: quorum >Affects Versions: 3.4.3 >Reporter: Jacky007 >Assignee: Flavio Junqueira >Priority: Major > Fix For: 3.6.0, 3.5.5 > > Attachments: ZOOKEEPER-1549-3.4.patch, ZOOKEEPER-1549-learner.patch, > case.patch > > > the trunc code (from ZOOKEEPER-1154?) cannot work correct if the snapshot is > not correct. > here is scenario(similar to 1154): > Initial Condition > 1.Lets say there are three nodes in the ensemble A,B,C with A being the > leader > 2.The current epoch is 7. > 3.For simplicity of the example, lets say zxid is a two digit number, > with epoch being the first digit. > 4.The zxid is 73 > 5.All the nodes have seen the change 73 and have persistently logged it. > Step 1 > Request with zxid 74 is issued. The leader A writes it to the log but there > is a crash of the entire ensemble and B,C never write the change 74 to their > log. > Step 2 > A,B restart, A is elected as the new leader, and A will load data and take a > clean snapshot(change 74 is in it), then send diff to B, but B died before > sync with A. A died later. > Step 3 > B,C restart, A is still down > B,C form the quorum > B is the new leader. Lets say B minCommitLog is 71 and maxCommitLog is 73 > epoch is now 8, zxid is 80 > Request with zxid 81 is successful. On B, minCommitLog is now 71, > maxCommitLog is 81 > Step 4 > A starts up. It applies the change in request with zxid 74 to its in-memory > data tree > A contacts B to registerAsFollower and provides 74 as its ZxId > Since 71<=74<=81, B decides to send A the diff. > Problem: > The problem with the above sequence is that after truncate the log, A will > load the snapshot again which is not correct. > In 3.3 branch, FileTxnSnapLog.restore does not call listener(ZOOKEEPER-874), > the leader will send a snapshot to follower, it will not be a problem. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (ZOOKEEPER-925) Consider maven site generation to replace our forrest site and documentation generation
[ https://issues.apache.org/jira/browse/ZOOKEEPER-925?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Penzes updated ZOOKEEPER-925: --- Affects Version/s: 3.6.0 3.5.4 3.4.13 > Consider maven site generation to replace our forrest site and documentation > generation > --- > > Key: ZOOKEEPER-925 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-925 > Project: ZooKeeper > Issue Type: Task > Components: documentation >Affects Versions: 3.5.4, 3.6.0, 3.4.13 >Reporter: Patrick Hunt >Assignee: Tamas Penzes >Priority: Blocker > Fix For: 3.6.0, 3.5.5, 3.4.14 > > Attachments: CMS_w_RST.patch, ZOOKEEPER-925.patch, ZOOKEEPER-925.patch > > > See WHIRR-19 for some background. > In whirr we looked at a number of site/doc generation facilities. In the end > Maven site generation plugin turned out to be by far the best option. You can > see our nascent site here (no attempt at styling,etc so far): > http://incubator.apache.org/whirr/ > In particular take a look at the quick start: > http://incubator.apache.org/whirr/quick-start-guide.html > which was generated from > http://svn.apache.org/repos/asf/incubator/whirr/trunk/src/site/confluence/quick-start-guide.confluence > notice this was standard wiki markup (confluence wiki markup, same as > available from apache) > You can read more about mvn site plugin here: > http://maven.apache.org/guides/mini/guide-site.html > Notice that other formats are available, not just confluence markup, also > note that you can use different markup formats if you like in the same site > (although probably not a great idea, but in some cases might be handy, for > example whirr uses the confluence wiki, so we can pretty much copy/paste > source docs from wiki to our site (svn) if we like) > Re maven vs our current ant based build. It's probably a good idea for us to > move the build to maven at some point. We could initially move just the doc > generation, and then incrementally move functionality from build.xml to mvn > over a longer time period. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (ZOOKEEPER-3155) Remove Forrest XMLs and their build process from the project
[ https://issues.apache.org/jira/browse/ZOOKEEPER-3155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Penzes updated ZOOKEEPER-3155: Priority: Blocker (was: Major) > Remove Forrest XMLs and their build process from the project > > > Key: ZOOKEEPER-3155 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3155 > Project: ZooKeeper > Issue Type: Sub-task >Affects Versions: 3.5.4, 3.6.0, 3.4.13 >Reporter: Tamas Penzes >Assignee: Tamas Penzes >Priority: Blocker > Labels: pull-request-available > Fix For: 3.6.0, 3.5.5, 3.4.14 > > Time Spent: 1h 40m > Remaining Estimate: 0h > > Remove obsoleted Forrest XML files and their build process from the project. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (ZOOKEEPER-925) Consider maven site generation to replace our forrest site and documentation generation
[ https://issues.apache.org/jira/browse/ZOOKEEPER-925?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Penzes updated ZOOKEEPER-925: --- Fix Version/s: 3.4.14 3.5.5 3.6.0 > Consider maven site generation to replace our forrest site and documentation > generation > --- > > Key: ZOOKEEPER-925 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-925 > Project: ZooKeeper > Issue Type: Task > Components: documentation >Affects Versions: 3.5.4, 3.6.0, 3.4.13 >Reporter: Patrick Hunt >Assignee: Tamas Penzes >Priority: Blocker > Fix For: 3.6.0, 3.5.5, 3.4.14 > > Attachments: CMS_w_RST.patch, ZOOKEEPER-925.patch, ZOOKEEPER-925.patch > > > See WHIRR-19 for some background. > In whirr we looked at a number of site/doc generation facilities. In the end > Maven site generation plugin turned out to be by far the best option. You can > see our nascent site here (no attempt at styling,etc so far): > http://incubator.apache.org/whirr/ > In particular take a look at the quick start: > http://incubator.apache.org/whirr/quick-start-guide.html > which was generated from > http://svn.apache.org/repos/asf/incubator/whirr/trunk/src/site/confluence/quick-start-guide.confluence > notice this was standard wiki markup (confluence wiki markup, same as > available from apache) > You can read more about mvn site plugin here: > http://maven.apache.org/guides/mini/guide-site.html > Notice that other formats are available, not just confluence markup, also > note that you can use different markup formats if you like in the same site > (although probably not a great idea, but in some cases might be handy, for > example whirr uses the confluence wiki, so we can pretty much copy/paste > source docs from wiki to our site (svn) if we like) > Re maven vs our current ant based build. It's probably a good idea for us to > move the build to maven at some point. We could initially move just the doc > generation, and then incrementally move functionality from build.xml to mvn > over a longer time period. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (ZOOKEEPER-925) Consider maven site generation to replace our forrest site and documentation generation
[ https://issues.apache.org/jira/browse/ZOOKEEPER-925?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Penzes updated ZOOKEEPER-925: --- Priority: Blocker (was: Major) > Consider maven site generation to replace our forrest site and documentation > generation > --- > > Key: ZOOKEEPER-925 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-925 > Project: ZooKeeper > Issue Type: Task > Components: documentation >Affects Versions: 3.5.4, 3.6.0, 3.4.13 >Reporter: Patrick Hunt >Assignee: Tamas Penzes >Priority: Blocker > Fix For: 3.6.0, 3.5.5, 3.4.14 > > Attachments: CMS_w_RST.patch, ZOOKEEPER-925.patch, ZOOKEEPER-925.patch > > > See WHIRR-19 for some background. > In whirr we looked at a number of site/doc generation facilities. In the end > Maven site generation plugin turned out to be by far the best option. You can > see our nascent site here (no attempt at styling,etc so far): > http://incubator.apache.org/whirr/ > In particular take a look at the quick start: > http://incubator.apache.org/whirr/quick-start-guide.html > which was generated from > http://svn.apache.org/repos/asf/incubator/whirr/trunk/src/site/confluence/quick-start-guide.confluence > notice this was standard wiki markup (confluence wiki markup, same as > available from apache) > You can read more about mvn site plugin here: > http://maven.apache.org/guides/mini/guide-site.html > Notice that other formats are available, not just confluence markup, also > note that you can use different markup formats if you like in the same site > (although probably not a great idea, but in some cases might be handy, for > example whirr uses the confluence wiki, so we can pretty much copy/paste > source docs from wiki to our site (svn) if we like) > Re maven vs our current ant based build. It's probably a good idea for us to > move the build to maven at some point. We could initially move just the doc > generation, and then incrementally move functionality from build.xml to mvn > over a longer time period. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (ZOOKEEPER-3155) Remove Forrest XMLs and their build process from the project
[ https://issues.apache.org/jira/browse/ZOOKEEPER-3155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Penzes updated ZOOKEEPER-3155: Fix Version/s: 3.4.14 3.5.5 3.6.0 > Remove Forrest XMLs and their build process from the project > > > Key: ZOOKEEPER-3155 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3155 > Project: ZooKeeper > Issue Type: Sub-task >Affects Versions: 3.5.4, 3.6.0, 3.4.13 >Reporter: Tamas Penzes >Assignee: Tamas Penzes >Priority: Major > Labels: pull-request-available > Fix For: 3.6.0, 3.5.5, 3.4.14 > > Time Spent: 1h 40m > Remaining Estimate: 0h > > Remove obsoleted Forrest XML files and their build process from the project. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (ZOOKEEPER-3155) Remove Forrest XMLs and their build process from the project
[ https://issues.apache.org/jira/browse/ZOOKEEPER-3155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tamas Penzes updated ZOOKEEPER-3155: Affects Version/s: 3.6.0 3.5.4 3.4.13 > Remove Forrest XMLs and their build process from the project > > > Key: ZOOKEEPER-3155 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3155 > Project: ZooKeeper > Issue Type: Sub-task >Affects Versions: 3.5.4, 3.6.0, 3.4.13 >Reporter: Tamas Penzes >Assignee: Tamas Penzes >Priority: Major > Labels: pull-request-available > Fix For: 3.6.0, 3.5.5, 3.4.14 > > Time Spent: 1h 40m > Remaining Estimate: 0h > > Remove obsoleted Forrest XML files and their build process from the project. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (ZOOKEEPER-3021) Umbrella: Migrate project structure to Maven build
[
https://issues.apache.org/jira/browse/ZOOKEEPER-3021?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Penzes updated ZOOKEEPER-3021:
Priority: Blocker (was: Major)
> Umbrella: Migrate project structure to Maven build
> --
>
> Key: ZOOKEEPER-3021
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3021
> Project: ZooKeeper
> Issue Type: Improvement
> Components: build, build-infrastructure, scripts
>Affects Versions: 3.5.4, 3.6.0, 3.4.13
>Reporter: Norbert Kalmar
>Assignee: Norbert Kalmar
>Priority: Blocker
> Fix For: 3.6.0, 3.5.5, 3.4.14
>
>
> In multiple steps, Maven should replace current ant build in ZooKeeper.
> First phase - separate project structure that requires no code change:
> {noformat}
> zookeeper
> |-bin
> |-conf
> |-zk-client
> | |-zk-client-c
> |-zk-contrib
> | |-zk-contrib-fatjar
> | |-zk-contrib-huebrowser
> | |-zk-contrib-loggraph
> | |-zk-contrib-monitoring
> | |-zk-contrib-rest
> | |-zk-contrib-zkfuse
> | |-zk-contrib-zkperl
> | |-zk-contrib-zkpython
> | |-zk-contrib-zktreeutil
> | \-zk-contrib-zooinspector
> |-zk-docs
> |-zk-it (integration tests)
> |-zk-server
> |-zk-recipes
> | |-zk-recipes-election
> | |-zk-recipes-lock
> \ \-zk-recipes-queue
> {noformat}
>
>
> Second phase - separate modules that require code changes:
> {noformat}
> zookeeper
> |-bin
> |-conf
> *|-jute*
> |-zk-client
> | |-zk-client-c
> *| |-zk-client-java* (separated from zk-server)
> *| \-zk-client-go* (or any other language)
> *|-zk-common*
> |-zk-contrib
> | |-zk-contrib-fatjar
> | |-zk-contrib-huebrowser
> | |-zk-contrib-loggraph
> | |-zk-contrib-monitoring
> | |-zk-contrib-rest
> | |-zk-contrib-zkfuse
> | |-zk-contrib-zkperl
> | |-zk-contrib-zkpython
> | |-zk-contrib-zktreeutil
> | \-zk-contrib-zooinspector
> |-zk-docs
> |-zk-it (integration tests)
> |-zk-server
> |-zk-recipes
> | |-zk-recipes-election
> | |-zk-recipes-lock
> \ \-zk-recipes-queue
> {noformat}
>
> Every module will have the same maven structure:
> {noformat}
> zk-something
> |-src
> | |-main
> | | |-java
> | | | \org...
> | | \resources
> | \test (unit tests only?)
> | |-java
> | | \org...
> | \resources
> \pom.xml (build.xml, build.gradle?)
> {noformat}
> There is already ZOOKEEPER-1078, but it's main approach is to create a maven
> proxy on top of ant.
> The main idea here is to replace ant with "pure" maven, and update the
> project structure accordingly.
> It is also worth noting, that backporting only the package changes to 3.4 is
> a good practice for future backport commits. Maven build implementation not
> needed, just the directory structuro to be compatible with 3.5/master.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (ZOOKEEPER-3021) Umbrella: Migrate project structure to Maven build
[
https://issues.apache.org/jira/browse/ZOOKEEPER-3021?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tamas Penzes updated ZOOKEEPER-3021:
Fix Version/s: 3.4.14
3.6.0
> Umbrella: Migrate project structure to Maven build
> --
>
> Key: ZOOKEEPER-3021
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3021
> Project: ZooKeeper
> Issue Type: Improvement
> Components: build, build-infrastructure, scripts
>Affects Versions: 3.5.4, 3.6.0, 3.4.13
>Reporter: Norbert Kalmar
>Assignee: Norbert Kalmar
>Priority: Blocker
> Fix For: 3.6.0, 3.5.5, 3.4.14
>
>
> In multiple steps, Maven should replace current ant build in ZooKeeper.
> First phase - separate project structure that requires no code change:
> {noformat}
> zookeeper
> |-bin
> |-conf
> |-zk-client
> | |-zk-client-c
> |-zk-contrib
> | |-zk-contrib-fatjar
> | |-zk-contrib-huebrowser
> | |-zk-contrib-loggraph
> | |-zk-contrib-monitoring
> | |-zk-contrib-rest
> | |-zk-contrib-zkfuse
> | |-zk-contrib-zkperl
> | |-zk-contrib-zkpython
> | |-zk-contrib-zktreeutil
> | \-zk-contrib-zooinspector
> |-zk-docs
> |-zk-it (integration tests)
> |-zk-server
> |-zk-recipes
> | |-zk-recipes-election
> | |-zk-recipes-lock
> \ \-zk-recipes-queue
> {noformat}
>
>
> Second phase - separate modules that require code changes:
> {noformat}
> zookeeper
> |-bin
> |-conf
> *|-jute*
> |-zk-client
> | |-zk-client-c
> *| |-zk-client-java* (separated from zk-server)
> *| \-zk-client-go* (or any other language)
> *|-zk-common*
> |-zk-contrib
> | |-zk-contrib-fatjar
> | |-zk-contrib-huebrowser
> | |-zk-contrib-loggraph
> | |-zk-contrib-monitoring
> | |-zk-contrib-rest
> | |-zk-contrib-zkfuse
> | |-zk-contrib-zkperl
> | |-zk-contrib-zkpython
> | |-zk-contrib-zktreeutil
> | \-zk-contrib-zooinspector
> |-zk-docs
> |-zk-it (integration tests)
> |-zk-server
> |-zk-recipes
> | |-zk-recipes-election
> | |-zk-recipes-lock
> \ \-zk-recipes-queue
> {noformat}
>
> Every module will have the same maven structure:
> {noformat}
> zk-something
> |-src
> | |-main
> | | |-java
> | | | \org...
> | | \resources
> | \test (unit tests only?)
> | |-java
> | | \org...
> | \resources
> \pom.xml (build.xml, build.gradle?)
> {noformat}
> There is already ZOOKEEPER-1078, but it's main approach is to create a maven
> proxy on top of ant.
> The main idea here is to replace ant with "pure" maven, and update the
> project structure accordingly.
> It is also worth noting, that backporting only the package changes to 3.4 is
> a good practice for future backport commits. Maven build implementation not
> needed, just the directory structuro to be compatible with 3.5/master.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
