[jira] Updated: (ZOOKEEPER-542) c-client can spin when server unresponsive
[ https://issues.apache.org/jira/browse/ZOOKEEPER-542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Reed updated ZOOKEEPER-542: Attachment: ZOOKEEPER-542.patch added comments c-client can spin when server unresponsive -- Key: ZOOKEEPER-542 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-542 Project: Zookeeper Issue Type: Bug Components: c client Affects Versions: 3.2.0 Reporter: Christian Wiedmann Fix For: 3.3.0 Attachments: ZOOKEEPER-542.patch, ZOOKEEPER-542.patch Due to a mismatch between zookeeper_interest() and zookeeper_process(), when the zookeeper server is unresponsive the client can spin when reconnecting to the server. In particular, zookeeper_interest() adds ZOOKEEPER_WRITE whenever there is data to be sent, but flush_send_queue() only writes the data if the state is ZOO_CONNECTED_STATE. When in ZOO_ASSOCIATING_STATE, this results in spinning. This probably doesn't affect production, but I had a runaway process in a development deployment that caused performance issues on the node. This is easy to reproduce in a single node environment by doing a kill -STOP on the server and waiting for the session timeout. Patch to be added. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-462) Last hint for open ledger
[ https://issues.apache.org/jira/browse/ZOOKEEPER-462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12764535#action_12764535 ] Benjamin Reed commented on ZOOKEEPER-462: - if the client asks all the bookies he may not be able to get the last committed entry if we allow for failures. the safest thing to do would be to get the last entry from each bookie and then use the entry id in the last committed field. that would mean that you would never be able to see the actual last committed record. i think it would be good to allow the client to specify the last committed entry on the open. that way we allow the client to figure out the last committed record any way it wants, via communication from other processes for example, and it would keep the open code simple: it would just use the id it wouldn't need to worry about recovery. Last hint for open ledger - Key: ZOOKEEPER-462 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-462 Project: Zookeeper Issue Type: New Feature Components: contrib-bookkeeper Reporter: Flavio Paiva Junqueira Assignee: Flavio Paiva Junqueira Fix For: 3.3.0 Attachments: ZOOKEEPER-462.patch In some use cases of BookKeeper, it is useful to be able to read from a ledger before closing the ledger. To enable such a feature, the writer has to be able to communicate to a reader how many entries it has been able to write successfully. The main idea of this jira is to continuously update a znode with the number of successful writes, and a reader can, for example, watch the node for changes. I was thinking of having a configuration parameter to state how often a writer should update the hint on ZooKeeper (e.g., every 1000 requests, every 10,000 requests). Clearly updating more often increases the overhead of writing to ZooKeeper, although the impact on the performance of writes to BookKeeper should be minimal given that we make an asynchronous call to update the hint. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-562) c client can flood server with pings if tcp send queue filled
[ https://issues.apache.org/jira/browse/ZOOKEEPER-562?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Reed updated ZOOKEEPER-562: Status: Patch Available (was: Open) c client can flood server with pings if tcp send queue filled - Key: ZOOKEEPER-562 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-562 Project: Zookeeper Issue Type: Bug Components: c client Affects Versions: 3.2.1 Reporter: Patrick Hunt Assignee: Benjamin Reed Priority: Blocker Fix For: 3.2.2, 3.3.0 Attachments: ZOOKEEPER-562.patch The c client can flood the server with pings if the tcp queue is filled. Say the cluster is overloaded and shuts down the recv processing a c client can send a ping, but since last_send is only updated on successful pushing of data into the socket, if flush_send_queue fails to send any data (send_buffer returns 0) then last_send is not updated and zookeeper_interest will again send a ping the next time it is woken - which could be 0 if recv_to is close to 0, easily could happen if server is not sending data to the client. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-562) c client can flood server with pings if tcp send queue filled
[ https://issues.apache.org/jira/browse/ZOOKEEPER-562?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Reed updated ZOOKEEPER-562: Attachment: ZOOKEEPER-562.patch this patch fixes the problem by only sending a ping if there isn't something already queued. the test checks for clients sending gratuitous pings. c client can flood server with pings if tcp send queue filled - Key: ZOOKEEPER-562 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-562 Project: Zookeeper Issue Type: Bug Components: c client Affects Versions: 3.2.1 Reporter: Patrick Hunt Assignee: Benjamin Reed Priority: Blocker Fix For: 3.2.2, 3.3.0 Attachments: ZOOKEEPER-562.patch The c client can flood the server with pings if the tcp queue is filled. Say the cluster is overloaded and shuts down the recv processing a c client can send a ping, but since last_send is only updated on successful pushing of data into the socket, if flush_send_queue fails to send any data (send_buffer returns 0) then last_send is not updated and zookeeper_interest will again send a ping the next time it is woken - which could be 0 if recv_to is close to 0, easily could happen if server is not sending data to the client. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-568) SyncRequestProcessor snapping too frequently - counts non-log events as log events
[ https://issues.apache.org/jira/browse/ZOOKEEPER-568?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12773280#action_12773280 ] Benjamin Reed commented on ZOOKEEPER-568: - i think that r.nextInt is in the right place. we should document why it is there. (so that all the replicas aren't snap shotting at the same time.) apart from not counting the read only requests, we should also process them immediately if there are no pending writes. SyncRequestProcessor snapping too frequently - counts non-log events as log events -- Key: ZOOKEEPER-568 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-568 Project: Zookeeper Issue Type: Bug Affects Versions: 3.2.1 Reporter: Patrick Hunt Fix For: 3.3.0 Noticed the following issues in SyncRequestProcessor 1) logCount is incremented even for non-log events (say getData) txnlog should return indication if request was logged or not (if hdr ==null it returns) also: 2) move r.nextInt below logCount++ (ie if an actual log event) 3) fix indentation after txnlog.append (for some reason has unnecessary 4 char indent) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-568) SyncRequestProcessor snapping too frequently - counts non-log events as log events
[ https://issues.apache.org/jira/browse/ZOOKEEPER-568?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Reed updated ZOOKEEPER-568: Resolution: Fixed Status: Resolved (was: Patch Available) Committed revision 833639. SyncRequestProcessor snapping too frequently - counts non-log events as log events -- Key: ZOOKEEPER-568 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-568 Project: Zookeeper Issue Type: Bug Affects Versions: 3.2.1 Reporter: Patrick Hunt Assignee: Patrick Hunt Fix For: 3.3.0 Attachments: ZOOKEEPER-568.patch Noticed the following issues in SyncRequestProcessor 1) logCount is incremented even for non-log events (say getData) txnlog should return indication if request was logged or not (if hdr ==null it returns) also: 2) move r.nextInt below logCount++ (ie if an actual log event) 3) fix indentation after txnlog.append (for some reason has unnecessary 4 char indent) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-570) AsyncHammerTest is broken, callbacks need to validate rc parameter
[ https://issues.apache.org/jira/browse/ZOOKEEPER-570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12774833#action_12774833 ] Benjamin Reed commented on ZOOKEEPER-570: - +1 good job. what a messed up patch! AsyncHammerTest is broken, callbacks need to validate rc parameter -- Key: ZOOKEEPER-570 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-570 Project: Zookeeper Issue Type: Bug Components: tests Affects Versions: 3.2.1 Reporter: Patrick Hunt Assignee: Patrick Hunt Priority: Critical Fix For: 3.2.2, 3.3.0 Attachments: ZOOKEEPER-570.patch, ZOOKEEPER-570.patch the asynchammertest is not validating the rc in the callback, more serious is that it is using path in the create callback to delete the node, rather than name (which is important in the case of a sequential node creation as in this case) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-570) AsyncHammerTest is broken, callbacks need to validate rc parameter
[ https://issues.apache.org/jira/browse/ZOOKEEPER-570?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Reed updated ZOOKEEPER-570: Hadoop Flags: [Reviewed] AsyncHammerTest is broken, callbacks need to validate rc parameter -- Key: ZOOKEEPER-570 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-570 Project: Zookeeper Issue Type: Bug Components: tests Affects Versions: 3.2.1 Reporter: Patrick Hunt Assignee: Patrick Hunt Priority: Critical Fix For: 3.2.2, 3.3.0 Attachments: ZOOKEEPER-570.patch, ZOOKEEPER-570.patch the asynchammertest is not validating the rc in the callback, more serious is that it is using path in the create callback to delete the node, rather than name (which is important in the case of a sequential node creation as in this case) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-425) Add OSGi metadata to zookeeper.jar
[ https://issues.apache.org/jira/browse/ZOOKEEPER-425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12776538#action_12776538 ] Benjamin Reed commented on ZOOKEEPER-425: - sorry i didn't notice this sooner. this is a great idea, and certainly reasonable. i think the import and export packages statement is incorrect. we should list the exact dependencies. Add OSGi metadata to zookeeper.jar -- Key: ZOOKEEPER-425 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-425 Project: Zookeeper Issue Type: Improvement Components: build Affects Versions: 3.1.1 Reporter: David Bosschaert Attachments: MANIFEST.MF After adding OSGi metadata to zookeeper.jar it can be used as both an OSGi bundle as well as an ordinary jar file. In the CXF/DOSGi project the buildsystem does this using the maven-bundle-plugin: http://svn.apache.org/repos/asf/cxf/dosgi/trunk/discovery/distributed/zookeeper-wrapper/pom.xml The MANIFEST.MF generated by maven-bundle-plugin is attached to this bug, this works for the CXF/DOSGi project. If your buildsystem isn't using maven, I would advise to use bnd (http://www.aqute.biz/Code/Bnd). BND defines its own ant task in which you should be able to use more or less the same instructions as were used in maven: instructions Bundle-NameZooKeeper bundle/Bundle-Name Bundle-DescriptionThis bundle contains the ZooKeeper library/Bundle-Description Bundle-SymbolicNameorg.apache.hadoop.zookeeper/Bundle-SymbolicName Bundle-Version3.1.1/Bundle-Version Import-Package*/Import-Package Export-Package*;version=3.1.1/Export-Package /instructions Oh and one other thing. Is it really necessary to put the source code in the Jar file too? I would put that in a separate source distribution :) See also: http://mail-archives.apache.org/mod_mbox/hadoop-zookeeper-user/200905.mbox/%3c4a2009b1.3030...@yahoo-inc.com%3e -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-425) Add OSGi metadata to zookeeper.jar
[ https://issues.apache.org/jira/browse/ZOOKEEPER-425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12776610#action_12776610 ] Benjamin Reed commented on ZOOKEEPER-425: - right these are osgi specific tags that will get ignored normally. Add OSGi metadata to zookeeper.jar -- Key: ZOOKEEPER-425 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-425 Project: Zookeeper Issue Type: Improvement Components: build Affects Versions: 3.1.1 Reporter: David Bosschaert Attachments: MANIFEST.MF After adding OSGi metadata to zookeeper.jar it can be used as both an OSGi bundle as well as an ordinary jar file. In the CXF/DOSGi project the buildsystem does this using the maven-bundle-plugin: http://svn.apache.org/repos/asf/cxf/dosgi/trunk/discovery/distributed/zookeeper-wrapper/pom.xml The MANIFEST.MF generated by maven-bundle-plugin is attached to this bug, this works for the CXF/DOSGi project. If your buildsystem isn't using maven, I would advise to use bnd (http://www.aqute.biz/Code/Bnd). BND defines its own ant task in which you should be able to use more or less the same instructions as were used in maven: instructions Bundle-NameZooKeeper bundle/Bundle-Name Bundle-DescriptionThis bundle contains the ZooKeeper library/Bundle-Description Bundle-SymbolicNameorg.apache.hadoop.zookeeper/Bundle-SymbolicName Bundle-Version3.1.1/Bundle-Version Import-Package*/Import-Package Export-Package*;version=3.1.1/Export-Package /instructions Oh and one other thing. Is it really necessary to put the source code in the Jar file too? I would put that in a separate source distribution :) See also: http://mail-archives.apache.org/mod_mbox/hadoop-zookeeper-user/200905.mbox/%3c4a2009b1.3030...@yahoo-inc.com%3e -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-425) Add OSGi metadata to zookeeper.jar
[ https://issues.apache.org/jira/browse/ZOOKEEPER-425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12776614#action_12776614 ] Benjamin Reed commented on ZOOKEEPER-425: - oh sorry david. so i still have the same concern with the full manifest.mf, but before that i was wondering: are you trying to provide the bundle so that other bundles can use zookeeper or so that the bundle can start up a zookeeper server? most of the packages imported and exported are internal to zookeeper and should be kept private. if we want to just provide access to the client API we should just list org.apache.zookeeper and org.apache.zookeeper.data (possibly org.apache.zookeeper.version). we should also use the script to set the version rather than hard code it. if you want to start the server, we should really have a separate package with just the classes/interfaces needed to manage a server instance and export that. the only import we need is log4j. is there already a standard log4j bundle? Add OSGi metadata to zookeeper.jar -- Key: ZOOKEEPER-425 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-425 Project: Zookeeper Issue Type: Improvement Components: build Affects Versions: 3.1.1 Reporter: David Bosschaert Attachments: MANIFEST.MF After adding OSGi metadata to zookeeper.jar it can be used as both an OSGi bundle as well as an ordinary jar file. In the CXF/DOSGi project the buildsystem does this using the maven-bundle-plugin: http://svn.apache.org/repos/asf/cxf/dosgi/trunk/discovery/distributed/zookeeper-wrapper/pom.xml The MANIFEST.MF generated by maven-bundle-plugin is attached to this bug, this works for the CXF/DOSGi project. If your buildsystem isn't using maven, I would advise to use bnd (http://www.aqute.biz/Code/Bnd). BND defines its own ant task in which you should be able to use more or less the same instructions as were used in maven: instructions Bundle-NameZooKeeper bundle/Bundle-Name Bundle-DescriptionThis bundle contains the ZooKeeper library/Bundle-Description Bundle-SymbolicNameorg.apache.hadoop.zookeeper/Bundle-SymbolicName Bundle-Version3.1.1/Bundle-Version Import-Package*/Import-Package Export-Package*;version=3.1.1/Export-Package /instructions Oh and one other thing. Is it really necessary to put the source code in the Jar file too? I would put that in a separate source distribution :) See also: http://mail-archives.apache.org/mod_mbox/hadoop-zookeeper-user/200905.mbox/%3c4a2009b1.3030...@yahoo-inc.com%3e -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-368) Observers
[ https://issues.apache.org/jira/browse/ZOOKEEPER-368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12776840#action_12776840 ] Benjamin Reed commented on ZOOKEEPER-368: - jeff, i agree that we shouldn't hold a patch to fix a bug somewhere else, but we also generally try to keep our trunk correct, so generally we want to see doc, test, and correct behavior before committing especially with something that touches the core. having said that i think the missing doc, functionality, and testing is confined to the observer function, so i think we should commit it and fix the rest of the observer code as separate patches to avoid having to refresh the patch. Observers - Key: ZOOKEEPER-368 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-368 Project: Zookeeper Issue Type: New Feature Components: quorum Reporter: Flavio Paiva Junqueira Assignee: Henry Robinson Attachments: obs-refactor.patch, observer-refactor.patch, observers sync benchmark.png, observers.patch, ZOOKEEPER-368.patch, ZOOKEEPER-368.patch, ZOOKEEPER-368.patch, ZOOKEEPER-368.patch, ZOOKEEPER-368.patch, ZOOKEEPER-368.patch, ZOOKEEPER-368.patch, ZOOKEEPER-368.patch Currently, all servers of an ensemble participate actively in reaching agreement on the order of ZooKeeper transactions. That is, all followers receive proposals, acknowledge them, and receive commit messages from the leader. A leader issues commit messages once it receives acknowledgments from a quorum of followers. For cross-colo operation, it would be useful to have a third role: observer. Using Paxos terminology, observers are similar to learners. An observer does not participate actively in the agreement step of the atomic broadcast protocol. Instead, it only commits proposals that have been accepted by some quorum of followers. One simple solution to implement observers is to have the leader forwarding commit messages not only to followers but also to observers, and have observers applying transactions according to the order followers agreed upon. In the current implementation of the protocol, however, commit messages do not carry their corresponding transaction payload because all servers different from the leader are followers and followers receive such a payload first through a proposal message. Just forwarding commit messages as they currently are to an observer consequently is not sufficient. We have a couple of options: 1- Include the transaction payload along in commit messages to observers; 2- Send proposals to observers as well. Number 2 is simpler to implement because it doesn't require changing the protocol implementation, but it increases traffic slightly. The performance impact due to such an increase might be insignificant, though. For scalability purposes, we may consider having followers also forwarding commit messages to observers. With this option, observers can connect to followers, and receive messages from followers. This choice is important to avoid increasing the load on the leader with the number of observers. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-566) reqs four letter word (command port) returns no information
[ https://issues.apache.org/jira/browse/ZOOKEEPER-566?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Reed updated ZOOKEEPER-566: Hadoop Flags: [Reviewed] reqs four letter word (command port) returns no information - Key: ZOOKEEPER-566 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-566 Project: Zookeeper Issue Type: Bug Affects Versions: 3.2.1 Reporter: Patrick Hunt Assignee: Patrick Hunt Priority: Critical Fix For: 3.3.0 Attachments: ZOOKEEPER-566.patch the four letter word reqs doesn't do anything - it always returns empty data. Seems that outstanding field is always empty and never set. we should remove outstanding and also update the reqs code to correctly output the outstanding requests (if not possible then remove the cmd and update docs - although this is very useful command, hate to see us lose it) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-566) reqs four letter word (command port) returns no information
[ https://issues.apache.org/jira/browse/ZOOKEEPER-566?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Reed updated ZOOKEEPER-566: Resolution: Fixed Release Note: Committed revision 835515. Status: Resolved (was: Patch Available) reqs four letter word (command port) returns no information - Key: ZOOKEEPER-566 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-566 Project: Zookeeper Issue Type: Bug Affects Versions: 3.2.1 Reporter: Patrick Hunt Assignee: Patrick Hunt Priority: Critical Fix For: 3.3.0 Attachments: ZOOKEEPER-566.patch the four letter word reqs doesn't do anything - it always returns empty data. Seems that outstanding field is always empty and never set. we should remove outstanding and also update the reqs code to correctly output the outstanding requests (if not possible then remove the cmd and update docs - although this is very useful command, hate to see us lose it) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-567) javadoc for getchildren2 needs to mention new in 3.3.0
[ https://issues.apache.org/jira/browse/ZOOKEEPER-567?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Reed updated ZOOKEEPER-567: Hadoop Flags: [Reviewed] javadoc for getchildren2 needs to mention new in 3.3.0 Key: ZOOKEEPER-567 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-567 Project: Zookeeper Issue Type: Bug Components: c client, java client Reporter: Patrick Hunt Assignee: Patrick Hunt Fix For: 3.3.0 Attachments: ZOOKEEPER-567.patch the javadoc/cdoc for getchildren2 needs to mention that the methods are new in 3.3.0 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-544) improve client testability - allow test client to access connected server location
[ https://issues.apache.org/jira/browse/ZOOKEEPER-544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12778980#action_12778980 ] Benjamin Reed commented on ZOOKEEPER-544: - why do you have testableLocalSocketAddress in ZooKeeper? The cnxn object is protected. You don't need that method is ZooKeeper do you? improve client testability - allow test client to access connected server location -- Key: ZOOKEEPER-544 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-544 Project: Zookeeper Issue Type: Improvement Components: c client, java client, tests Reporter: Patrick Hunt Assignee: Patrick Hunt Fix For: 3.3.0 Attachments: ZOOKEEPER-544.patch This came up recently on the user list. If you are developing tests for your zk client you need to be able to access the server that your session is currently connected to. The reason is that your test needs to know which server in the quorum to shutdown in order to verify you are handling failover correctly. Similar for session expiration testing. however we should be careful, we prefer not to expose this to all clients, this is an implementation detail that we typically want to hide. also we should provide this in both the c and java clients I suspect we should add a protected method on ZooKeeper. This will make a higher bar (user will have to subclass) for the user to access this method. In tests it's fine, typically you want a TestableZooKeeper class anyway. In c we unfortunately have less options, we can just rely on docs for now. In both cases (c/java) we need to be very very clear in the docs that this is for testing only and to clearly define semantics. We should add the following at the same time: toString() method to ZooKeeper which includes server ip/port, client port, any other information deemed useful (connection stats like send/recv?) the java ZooKeeper is missing deterministic connection order that the c client has. this is also useful for testing. again, protected and clear docs that this is for testing purposes only! Any other things we should expose? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (ZOOKEEPER-582) ZooKeeper can revert to old data when a snapshot is created outside of normal processing
ZooKeeper can revert to old data when a snapshot is created outside of normal processing Key: ZOOKEEPER-582 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-582 Project: Zookeeper Issue Type: Bug Components: server Affects Versions: 3.2.1 Reporter: Benjamin Reed Fix For: 3.2.2 when zookeeper starts up it will restore the most recent state (latest zxid) it finds in the data directory. unfortunately, in the quorum version of zookeeper updates are logged using an epoch based on the latest log file in a directory. if there is a snapshot with a higher epoch than the log files, the zookeeper server will start logging using an epoch one higher than the highest log file. so if a data directory has a snapshot with an epoch of 27 and there are no log files, zookeeper will start logging changes using epoch 1. if the cluster restarts the state will be restored from the snapshot with the epoch of 27, which in effect, restores old data. normal operation of zookeeper will never result in this situation. this does not effect standalone zookeeper. a fix should make sure to use an epoch one higher than the current state, whether it comes from the snapshot or log, and should include a sanity check to make sure that a follower never connects to a leader that has a lower epoch than its own. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-547) Sanity check in QuorumCnxn Manager and quorum communication port.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-547?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Reed updated ZOOKEEPER-547: Resolution: Fixed Status: Resolved (was: Patch Available) Committed revision 881623. Sanity check in QuorumCnxn Manager and quorum communication port. - Key: ZOOKEEPER-547 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-547 Project: Zookeeper Issue Type: Bug Components: leaderElection, server Affects Versions: 3.2.0, 3.2.1 Reporter: Mahadev konar Assignee: Mahadev konar Fix For: 3.2.2, 3.3.0 Attachments: ZOOKEEPER-547.patch, ZOOKEEPER-547.patch, ZOOKEEPER-547.patch, ZOOKEEPER-547.patch We need to put some sanity checks in QuorumCnxnManager and the other quorum port for rogue clients. Sometimes a clients might get misconfigured and they might send random characters on such ports. We need to make sure that such rogue clients do not bring down the clients and need to put in some sanity checks with respect to packet lengths and deserialization. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-547) Sanity check in QuorumCnxn Manager and quorum communication port.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12779236#action_12779236 ] Benjamin Reed commented on ZOOKEEPER-547: - Committed revision 881641. (for branch 3.2.2) i had to pull in src/java/test/org/apache/zookeeper/PortAssignment.java from trunk. Sanity check in QuorumCnxn Manager and quorum communication port. - Key: ZOOKEEPER-547 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-547 Project: Zookeeper Issue Type: Bug Components: leaderElection, server Affects Versions: 3.2.0, 3.2.1 Reporter: Mahadev konar Assignee: Mahadev konar Fix For: 3.2.2, 3.3.0 Attachments: ZOOKEEPER-547.patch, ZOOKEEPER-547.patch, ZOOKEEPER-547.patch, ZOOKEEPER-547.patch We need to put some sanity checks in QuorumCnxnManager and the other quorum port for rogue clients. Sometimes a clients might get misconfigured and they might send random characters on such ports. We need to make sure that such rogue clients do not bring down the clients and need to put in some sanity checks with respect to packet lengths and deserialization. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-582) ZooKeeper can revert to old data when a snapshot is created outside of normal processing
[ https://issues.apache.org/jira/browse/ZOOKEEPER-582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Reed updated ZOOKEEPER-582: Attachment: test.patch this patch reproduces the problems outlined in this issue. ZooKeeper can revert to old data when a snapshot is created outside of normal processing Key: ZOOKEEPER-582 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-582 Project: Zookeeper Issue Type: Bug Components: server Affects Versions: 3.1.1, 3.2.1 Reporter: Benjamin Reed Priority: Blocker Fix For: 3.2.2, 3.1.2 Attachments: test.patch when zookeeper starts up it will restore the most recent state (latest zxid) it finds in the data directory. unfortunately, in the quorum version of zookeeper updates are logged using an epoch based on the latest log file in a directory. if there is a snapshot with a higher epoch than the log files, the zookeeper server will start logging using an epoch one higher than the highest log file. so if a data directory has a snapshot with an epoch of 27 and there are no log files, zookeeper will start logging changes using epoch 1. if the cluster restarts the state will be restored from the snapshot with the epoch of 27, which in effect, restores old data. normal operation of zookeeper will never result in this situation. this does not effect standalone zookeeper. a fix should make sure to use an epoch one higher than the current state, whether it comes from the snapshot or log, and should include a sanity check to make sure that a follower never connects to a leader that has a lower epoch than its own. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-532) java compiler should be target Java 1.5
[ https://issues.apache.org/jira/browse/ZOOKEEPER-532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Reed updated ZOOKEEPER-532: Hadoop Flags: [Reviewed] +1 java compiler should be target Java 1.5 --- Key: ZOOKEEPER-532 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-532 Project: Zookeeper Issue Type: Bug Affects Versions: 3.2.1 Reporter: Hiram Chirino Assignee: Hiram Chirino Fix For: 3.3.0 Attachments: ZOOKEEPER-532.patch, ZOOKEEPER-532.patch The jars released in 3.2.1 will not run on Java 1.5. With a small build change, it is possible to generate jars that will run on Java 1.5. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-532) java compiler should be target Java 1.5
[ https://issues.apache.org/jira/browse/ZOOKEEPER-532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Reed updated ZOOKEEPER-532: Resolution: Fixed Status: Resolved (was: Patch Available) Committed revision 881841. thanx hiram! java compiler should be target Java 1.5 --- Key: ZOOKEEPER-532 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-532 Project: Zookeeper Issue Type: Bug Affects Versions: 3.2.1 Reporter: Hiram Chirino Assignee: Hiram Chirino Fix For: 3.3.0 Attachments: ZOOKEEPER-532.patch, ZOOKEEPER-532.patch The jars released in 3.2.1 will not run on Java 1.5. With a small build change, it is possible to generate jars that will run on Java 1.5. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-519) Followerhandler should close the socket if it gets an exception on a write.
[
https://issues.apache.org/jira/browse/ZOOKEEPER-519?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Reed updated ZOOKEEPER-519:
Resolution: Fixed
Hadoop Flags: [Reviewed]
Status: Resolved (was: Patch Available)
Committed revision 881847.
Followerhandler should close the socket if it gets an exception on a write.
---
Key: ZOOKEEPER-519
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-519
Project: Zookeeper
Issue Type: Bug
Reporter: Mahadev konar
Assignee: Mahadev konar
Fix For: 3.3.0
Attachments: ZOOKEEPER-519.patch
We noticed this in our tests -
{code}
java.net.SocketException: Broken pipe
at java.net.SocketOutputStream.socketWrite0(Native Method)
at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92)
at java.net.SocketOutputStream.write(SocketOutputStream.java:136)
at java.io.BufferedOutputStream.write(BufferedOutputStream.java:105)
at java.io.DataOutputStream.write(DataOutputStream.java:90)
at java.io.FilterOutputStream.write(FilterOutputStream.java:80)
at
org.apache.jute.BinaryOutputArchive.writeBuffer(BinaryOutputArchive.java:122)
at org.apache.zookeeper.server.DataNode.serialize(DataNode.java:126)
at
org.apache.jute.BinaryOutputArchive.writeRecord(BinaryOutputArchive.java:126)
at
org.apache.zookeeper.server.DataTree.serializeNode(DataTree.java:878)
at
org.apache.zookeeper.server.DataTree.serializeNode(DataTree.java:890)
at
org.apache.zookeeper.server.DataTree.serializeNode(DataTree.java:890)
at
org.apache.zookeeper.server.DataTree.serializeNode(DataTree.java:890)
at
org.apache.zookeeper.server.DataTree.serializeNode(DataTree.java:890)
at
org.apache.zookeeper.server.DataTree.serializeNode(DataTree.java:890)
at org.apache.zookeeper.server.DataTree.serialize(DataTree.java:940)
at
org.apache.zookeeper.server.util.SerializeUtils.serializeSnapshot(SerializeUtils.java:102)
at
org.apache.zookeeper.server.ZooKeeperServer.serializeSnapshot(ZooKeeperServer.java:269)
at
org.apache.zookeeper.server.quorum.FollowerHandler.run(FollowerHandler.java:263)
{code}
So the followerhandler got an exception while writing to the socket but the
follower was still waiting on the socket for a read and got a read timeout
after 60 seconds or so. To just make sure we handle this rightly, we should
close the socket at the followerhandler when we get an excpetion, so that the
follower immediately recognizes that its disconnected from the leader.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-3) syncLimit has slightly different comments in the class header, and inline with the variable.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-3?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Reed updated ZOOKEEPER-3: -- Resolution: Fixed Hadoop Flags: [Reviewed] Status: Resolved (was: Patch Available) Committed revision 881849. syncLimit has slightly different comments in the class header, and inline with the variable. --- Key: ZOOKEEPER-3 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-3 Project: Zookeeper Issue Type: Bug Components: quorum Reporter: Benjamin Reed Assignee: Mahadev konar Priority: Trivial Fix For: 3.3.0 Attachments: ZOOKEEPER-3.patch syncLimit as documented in QuorumPeer is documented twice with two different aspects of in each instance. It should be better documented and unified. (Probably remove the second instance.) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-582) ZooKeeper can revert to old data when a snapshot is created outside of normal processing
[ https://issues.apache.org/jira/browse/ZOOKEEPER-582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Reed updated ZOOKEEPER-582: Status: Open (was: Patch Available) looks good mahadev just two things: 1) (minor) in getLastLoggedZxid() you should be useing maxLogZxid instead of calling getLastLoggedZxid() again. 2) when doing the sanity check with the leaders zxid you should be checking epochs not zxids. it is possible for a follower to see something later and have to truncate from the same epoch, put a follower should never see a later epoch. ZooKeeper can revert to old data when a snapshot is created outside of normal processing Key: ZOOKEEPER-582 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-582 Project: Zookeeper Issue Type: Bug Components: server Affects Versions: 3.2.1, 3.1.1 Reporter: Benjamin Reed Assignee: Mahadev konar Priority: Blocker Fix For: 3.2.2, 3.3.0, 3.1.2 Attachments: test.patch, ZOOKEEPER-582.patch, ZOOKEEPER-582.patch, ZOOKEEPER-582.patch, ZOOKEEPER-582.patch, ZOOKEEPER-582_3.1.patch, ZOOKEEPER-582_3.2.patch when zookeeper starts up it will restore the most recent state (latest zxid) it finds in the data directory. unfortunately, in the quorum version of zookeeper updates are logged using an epoch based on the latest log file in a directory. if there is a snapshot with a higher epoch than the log files, the zookeeper server will start logging using an epoch one higher than the highest log file. so if a data directory has a snapshot with an epoch of 27 and there are no log files, zookeeper will start logging changes using epoch 1. if the cluster restarts the state will be restored from the snapshot with the epoch of 27, which in effect, restores old data. normal operation of zookeeper will never result in this situation. this does not effect standalone zookeeper. a fix should make sure to use an epoch one higher than the current state, whether it comes from the snapshot or log, and should include a sanity check to make sure that a follower never connects to a leader that has a lower epoch than its own. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-576) docs need to be updated for session moved exception and how to handle it
[ https://issues.apache.org/jira/browse/ZOOKEEPER-576?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Reed updated ZOOKEEPER-576: Status: Patch Available (was: Open) docs need to be updated for session moved exception and how to handle it Key: ZOOKEEPER-576 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-576 Project: Zookeeper Issue Type: Bug Reporter: Mahadev konar Assignee: Benjamin Reed Fix For: 3.2.2, 3.3.0 Attachments: ZOOKEEPER-576.patch the handling and implications of session moved exception should be documented. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-582) ZooKeeper can revert to old data when a snapshot is created outside of normal processing
[ https://issues.apache.org/jira/browse/ZOOKEEPER-582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Reed updated ZOOKEEPER-582: Hadoop Flags: [Reviewed] +1 great job mahadev! ZooKeeper can revert to old data when a snapshot is created outside of normal processing Key: ZOOKEEPER-582 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-582 Project: Zookeeper Issue Type: Bug Components: server Affects Versions: 3.1.1, 3.2.1 Reporter: Benjamin Reed Assignee: Mahadev konar Priority: Blocker Fix For: 3.1.2, 3.2.2, 3.3.0 Attachments: test.patch, ZOOKEEPER-582.patch, ZOOKEEPER-582.patch, ZOOKEEPER-582.patch, ZOOKEEPER-582.patch, ZOOKEEPER-582.patch, ZOOKEEPER-582_3.1.patch, ZOOKEEPER-582_3.2.patch, ZOOKEEPER-582_3.2.patch when zookeeper starts up it will restore the most recent state (latest zxid) it finds in the data directory. unfortunately, in the quorum version of zookeeper updates are logged using an epoch based on the latest log file in a directory. if there is a snapshot with a higher epoch than the log files, the zookeeper server will start logging using an epoch one higher than the highest log file. so if a data directory has a snapshot with an epoch of 27 and there are no log files, zookeeper will start logging changes using epoch 1. if the cluster restarts the state will be restored from the snapshot with the epoch of 27, which in effect, restores old data. normal operation of zookeeper will never result in this situation. this does not effect standalone zookeeper. a fix should make sure to use an epoch one higher than the current state, whether it comes from the snapshot or log, and should include a sanity check to make sure that a follower never connects to a leader that has a lower epoch than its own. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-425) Add OSGi metadata to zookeeper.jar
[ https://issues.apache.org/jira/browse/ZOOKEEPER-425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Reed updated ZOOKEEPER-425: Hadoop Flags: [Reviewed] +1 to commit. no need for tests in this case. once we do the activator we will need test for that which will also cover the meta data as well. (the automatic testing is cool though isn't it?) unless there are any objections i think this is ready to commit. Add OSGi metadata to zookeeper.jar -- Key: ZOOKEEPER-425 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-425 Project: Zookeeper Issue Type: Improvement Components: build Reporter: David Bosschaert Fix For: 3.3.0 Attachments: buildxmlpatch.patch, MANIFEST.MF, zk_patch3.patch After adding OSGi metadata to zookeeper.jar it can be used as both an OSGi bundle as well as an ordinary jar file. In the CXF/DOSGi project the buildsystem does this using the maven-bundle-plugin: http://svn.apache.org/repos/asf/cxf/dosgi/trunk/discovery/distributed/zookeeper-wrapper/pom.xml The MANIFEST.MF generated by maven-bundle-plugin is attached to this bug, this works for the CXF/DOSGi project. If your buildsystem isn't using maven, I would advise to use bnd (http://www.aqute.biz/Code/Bnd). BND defines its own ant task in which you should be able to use more or less the same instructions as were used in maven: instructions Bundle-NameZooKeeper bundle/Bundle-Name Bundle-DescriptionThis bundle contains the ZooKeeper library/Bundle-Description Bundle-SymbolicNameorg.apache.hadoop.zookeeper/Bundle-SymbolicName Bundle-Version3.1.1/Bundle-Version Import-Package*/Import-Package Export-Package*;version=3.1.1/Export-Package /instructions Oh and one other thing. Is it really necessary to put the source code in the Jar file too? I would put that in a separate source distribution :) See also: http://mail-archives.apache.org/mod_mbox/hadoop-zookeeper-user/200905.mbox/%3c4a2009b1.3030...@yahoo-inc.com%3e -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-507) Improve error handling of BookKeeper client
[ https://issues.apache.org/jira/browse/ZOOKEEPER-507?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Reed updated ZOOKEEPER-507: Status: Open (was: Patch Available) waiting for ben to update the bookie doc Improve error handling of BookKeeper client --- Key: ZOOKEEPER-507 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-507 Project: Zookeeper Issue Type: Improvement Components: contrib-bookkeeper Reporter: Flavio Paiva Junqueira Assignee: Utkarsh Srivastava Attachments: ZOOKEEPER-507.patch Error handling is far from ideal currently in the BookKeeper client. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (ZOOKEEPER-425) Add OSGi metadata to zookeeper.jar
[ https://issues.apache.org/jira/browse/ZOOKEEPER-425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Reed reassigned ZOOKEEPER-425: --- Assignee: Benjamin Reed Add OSGi metadata to zookeeper.jar -- Key: ZOOKEEPER-425 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-425 Project: Zookeeper Issue Type: Improvement Components: build Reporter: David Bosschaert Assignee: Benjamin Reed Fix For: 3.3.0 Attachments: buildxmlpatch.patch, MANIFEST.MF, zk_patch3.patch After adding OSGi metadata to zookeeper.jar it can be used as both an OSGi bundle as well as an ordinary jar file. In the CXF/DOSGi project the buildsystem does this using the maven-bundle-plugin: http://svn.apache.org/repos/asf/cxf/dosgi/trunk/discovery/distributed/zookeeper-wrapper/pom.xml The MANIFEST.MF generated by maven-bundle-plugin is attached to this bug, this works for the CXF/DOSGi project. If your buildsystem isn't using maven, I would advise to use bnd (http://www.aqute.biz/Code/Bnd). BND defines its own ant task in which you should be able to use more or less the same instructions as were used in maven: instructions Bundle-NameZooKeeper bundle/Bundle-Name Bundle-DescriptionThis bundle contains the ZooKeeper library/Bundle-Description Bundle-SymbolicNameorg.apache.hadoop.zookeeper/Bundle-SymbolicName Bundle-Version3.1.1/Bundle-Version Import-Package*/Import-Package Export-Package*;version=3.1.1/Export-Package /instructions Oh and one other thing. Is it really necessary to put the source code in the Jar file too? I would put that in a separate source distribution :) See also: http://mail-archives.apache.org/mod_mbox/hadoop-zookeeper-user/200905.mbox/%3c4a2009b1.3030...@yahoo-inc.com%3e -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-587) client should log timeout negotiated with server
[ https://issues.apache.org/jira/browse/ZOOKEEPER-587?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Reed updated ZOOKEEPER-587: Hadoop Flags: [Reviewed] +1 looks good. client should log timeout negotiated with server Key: ZOOKEEPER-587 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-587 Project: Zookeeper Issue Type: Bug Components: c client, java client Affects Versions: 3.2.1 Reporter: Patrick Hunt Assignee: Patrick Hunt Fix For: 3.3.0 Attachments: ZOOKEEPER-587.patch, ZOOKEEPER-587.patch The ZK client should log the timeout negotiated with the server if the time is different than the timeout parameter specified by the client. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-588) remove unnecessary/annoying log of tostring error in Request.toString()
[
https://issues.apache.org/jira/browse/ZOOKEEPER-588?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Reed updated ZOOKEEPER-588:
Hadoop Flags: [Reviewed]
+1 good job. my only small quibble is the coding style violation:
)
{
rather than:
) {
remove unnecessary/annoying log of tostring error in Request.toString()
---
Key: ZOOKEEPER-588
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-588
Project: Zookeeper
Issue Type: Bug
Components: server
Affects Versions: 3.2.1
Reporter: Patrick Hunt
Assignee: Patrick Hunt
Priority: Minor
Fix For: 3.3.0
Attachments: ZOOKEEPER-588.patch
Why are we logging this? It's unnecessary and just annoying afaict. We should
remove it entirely.
2009-11-18 05:37:29,312 WARN org.apache.zookeeper.server.Request: Ignoring
exception during toString
java.nio.BufferUnderflowException
at java.nio.HeapByteBuffer.get(HeapByteBuffer.java:127)
at java.nio.ByteBuffer.get(ByteBuffer.java:675)
at org.apache.zookeeper.server.Request.toString(Request.java:199)
at java.lang.String.valueOf(String.java:2827)
at java.lang.StringBuilder.append(StringBuilder.java:115)
at
org.apache.zookeeper.server.quorum.CommitProcessor.processRequest(CommitProcessor.java:167)
at
org.apache.zookeeper.server.quorum.FollowerRequestProcessor.run(FollowerRequestProcessor.java:68)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-425) Add OSGi metadata to zookeeper.jar
[ https://issues.apache.org/jira/browse/ZOOKEEPER-425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12782058#action_12782058 ] Benjamin Reed commented on ZOOKEEPER-425: - yes just the buildxml.patch, the service instance will be registered in ZOOKEEPER-584 and we will need to pull in felix for that test. i would think that the activator for ZOOKEEPER-584 will go into a contrib and will will build its own little jar file. that way we only need to pull in felix for the contrib not for the whole of zookeeper. Add OSGi metadata to zookeeper.jar -- Key: ZOOKEEPER-425 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-425 Project: Zookeeper Issue Type: Improvement Components: build Reporter: David Bosschaert Assignee: David Bosschaert Fix For: 3.3.0 Attachments: buildxmlpatch.patch, MANIFEST.MF, zk_patch3.patch After adding OSGi metadata to zookeeper.jar it can be used as both an OSGi bundle as well as an ordinary jar file. In the CXF/DOSGi project the buildsystem does this using the maven-bundle-plugin: http://svn.apache.org/repos/asf/cxf/dosgi/trunk/discovery/distributed/zookeeper-wrapper/pom.xml The MANIFEST.MF generated by maven-bundle-plugin is attached to this bug, this works for the CXF/DOSGi project. If your buildsystem isn't using maven, I would advise to use bnd (http://www.aqute.biz/Code/Bnd). BND defines its own ant task in which you should be able to use more or less the same instructions as were used in maven: instructions Bundle-NameZooKeeper bundle/Bundle-Name Bundle-DescriptionThis bundle contains the ZooKeeper library/Bundle-Description Bundle-SymbolicNameorg.apache.hadoop.zookeeper/Bundle-SymbolicName Bundle-Version3.1.1/Bundle-Version Import-Package*/Import-Package Export-Package*;version=3.1.1/Export-Package /instructions Oh and one other thing. Is it really necessary to put the source code in the Jar file too? I would put that in a separate source distribution :) See also: http://mail-archives.apache.org/mod_mbox/hadoop-zookeeper-user/200905.mbox/%3c4a2009b1.3030...@yahoo-inc.com%3e -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-597) ASyncHammerTest is failing intermittently on hudson trunk
[ https://issues.apache.org/jira/browse/ZOOKEEPER-597?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Reed updated ZOOKEEPER-597: Status: Patch Available (was: Reopened) ASyncHammerTest is failing intermittently on hudson trunk - Key: ZOOKEEPER-597 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-597 Project: Zookeeper Issue Type: Bug Components: tests Reporter: Patrick Hunt Assignee: Patrick Hunt Priority: Critical Fix For: 3.3.0 Attachments: ZOOKEEPER-597.patch, ZOOKEEPER-597.patch ASyncHammerTest is failing intermittently on hudson trunk. There is no clear reason why this is happening, but it seems from the logs that a session connection to a follower is failing during session establishment - the failure seems to be a problem either on the follower or leader. The server gets the session create request, but it stalls in the request processor pipeline. (we see it go in, but we do not see it com eout) unfortunately all efforts to reproduce this on non-hudson trunk have failed. Even trying to reproduce by running on hudson host itself (manually) has failed. We need to instrument the client session creation code in the test to dump the thread stack if the session creation fails. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-597) ASyncHammerTest is failing intermittently on hudson trunk
[ https://issues.apache.org/jira/browse/ZOOKEEPER-597?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Reed updated ZOOKEEPER-597: Attachment: ZOOKEEPER-597.patch A runtime exception was killing the CommitProcessor. ASyncHammerTest is failing intermittently on hudson trunk - Key: ZOOKEEPER-597 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-597 Project: Zookeeper Issue Type: Bug Components: tests Reporter: Patrick Hunt Assignee: Patrick Hunt Priority: Critical Fix For: 3.3.0 Attachments: ZOOKEEPER-597.patch, ZOOKEEPER-597.patch ASyncHammerTest is failing intermittently on hudson trunk. There is no clear reason why this is happening, but it seems from the logs that a session connection to a follower is failing during session establishment - the failure seems to be a problem either on the follower or leader. The server gets the session create request, but it stalls in the request processor pipeline. (we see it go in, but we do not see it com eout) unfortunately all efforts to reproduce this on non-hudson trunk have failed. Even trying to reproduce by running on hudson host itself (manually) has failed. We need to instrument the client session creation code in the test to dump the thread stack if the session creation fails. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-597) ASyncHammerTest is failing intermittently on hudson trunk
[ https://issues.apache.org/jira/browse/ZOOKEEPER-597?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Reed updated ZOOKEEPER-597: Status: Open (was: Patch Available) ASyncHammerTest is failing intermittently on hudson trunk - Key: ZOOKEEPER-597 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-597 Project: Zookeeper Issue Type: Bug Components: tests Reporter: Patrick Hunt Assignee: Patrick Hunt Priority: Critical Fix For: 3.3.0 Attachments: ZOOKEEPER-597.patch, ZOOKEEPER-597.patch ASyncHammerTest is failing intermittently on hudson trunk. There is no clear reason why this is happening, but it seems from the logs that a session connection to a follower is failing during session establishment - the failure seems to be a problem either on the follower or leader. The server gets the session create request, but it stalls in the request processor pipeline. (we see it go in, but we do not see it com eout) unfortunately all efforts to reproduce this on non-hudson trunk have failed. Even trying to reproduce by running on hudson host itself (manually) has failed. We need to instrument the client session creation code in the test to dump the thread stack if the session creation fails. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-597) ASyncHammerTest is failing intermittently on hudson trunk
[ https://issues.apache.org/jira/browse/ZOOKEEPER-597?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Reed updated ZOOKEEPER-597: Status: Patch Available (was: Open) ASyncHammerTest is failing intermittently on hudson trunk - Key: ZOOKEEPER-597 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-597 Project: Zookeeper Issue Type: Bug Components: tests Reporter: Patrick Hunt Assignee: Patrick Hunt Priority: Critical Fix For: 3.3.0 Attachments: ZOOKEEPER-597.patch, ZOOKEEPER-597.patch ASyncHammerTest is failing intermittently on hudson trunk. There is no clear reason why this is happening, but it seems from the logs that a session connection to a follower is failing during session establishment - the failure seems to be a problem either on the follower or leader. The server gets the session create request, but it stalls in the request processor pipeline. (we see it go in, but we do not see it com eout) unfortunately all efforts to reproduce this on non-hudson trunk have failed. Even trying to reproduce by running on hudson host itself (manually) has failed. We need to instrument the client session creation code in the test to dump the thread stack if the session creation fails. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (ZOOKEEPER-607) improve bookkeeper overview
improve bookkeeper overview --- Key: ZOOKEEPER-607 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-607 Project: Zookeeper Issue Type: Improvement Components: contrib-bookkeeper Reporter: Benjamin Reed fix the overview section in the bookkeeper documentation to introduce the programmer/admin to bookkeeper before giving the details. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-597) ASyncHammerTest is failing intermittently on hudson trunk
[ https://issues.apache.org/jira/browse/ZOOKEEPER-597?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Reed updated ZOOKEEPER-597: Attachment: ZOOKEEPER-597.patch changes to cache Exception not Throwable. ASyncHammerTest is failing intermittently on hudson trunk - Key: ZOOKEEPER-597 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-597 Project: Zookeeper Issue Type: Bug Components: tests Reporter: Patrick Hunt Assignee: Patrick Hunt Priority: Critical Fix For: 3.3.0 Attachments: ZOOKEEPER-597.patch, ZOOKEEPER-597.patch, ZOOKEEPER-597.patch ASyncHammerTest is failing intermittently on hudson trunk. There is no clear reason why this is happening, but it seems from the logs that a session connection to a follower is failing during session establishment - the failure seems to be a problem either on the follower or leader. The server gets the session create request, but it stalls in the request processor pipeline. (we see it go in, but we do not see it com eout) unfortunately all efforts to reproduce this on non-hudson trunk have failed. Even trying to reproduce by running on hudson host itself (manually) has failed. We need to instrument the client session creation code in the test to dump the thread stack if the session creation fails. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-597) ASyncHammerTest is failing intermittently on hudson trunk
[ https://issues.apache.org/jira/browse/ZOOKEEPER-597?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Reed updated ZOOKEEPER-597: Assignee: Benjamin Reed (was: Patrick Hunt) Status: Patch Available (was: Open) ASyncHammerTest is failing intermittently on hudson trunk - Key: ZOOKEEPER-597 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-597 Project: Zookeeper Issue Type: Bug Components: tests Reporter: Patrick Hunt Assignee: Benjamin Reed Priority: Critical Fix For: 3.3.0 Attachments: ZOOKEEPER-597.patch, ZOOKEEPER-597.patch, ZOOKEEPER-597.patch ASyncHammerTest is failing intermittently on hudson trunk. There is no clear reason why this is happening, but it seems from the logs that a session connection to a follower is failing during session establishment - the failure seems to be a problem either on the follower or leader. The server gets the session create request, but it stalls in the request processor pipeline. (we see it go in, but we do not see it com eout) unfortunately all efforts to reproduce this on non-hudson trunk have failed. Even trying to reproduce by running on hudson host itself (manually) has failed. We need to instrument the client session creation code in the test to dump the thread stack if the session creation fails. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-597) ASyncHammerTest is failing intermittently on hudson trunk
[ https://issues.apache.org/jira/browse/ZOOKEEPER-597?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12784950#action_12784950 ] Benjamin Reed commented on ZOOKEEPER-597: - Committed revision 886241. (waiting for a couple of successful runs before i close) ASyncHammerTest is failing intermittently on hudson trunk - Key: ZOOKEEPER-597 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-597 Project: Zookeeper Issue Type: Bug Components: tests Reporter: Patrick Hunt Assignee: Benjamin Reed Priority: Critical Fix For: 3.3.0 Attachments: ZOOKEEPER-597.patch, ZOOKEEPER-597.patch, ZOOKEEPER-597.patch ASyncHammerTest is failing intermittently on hudson trunk. There is no clear reason why this is happening, but it seems from the logs that a session connection to a follower is failing during session establishment - the failure seems to be a problem either on the follower or leader. The server gets the session create request, but it stalls in the request processor pipeline. (we see it go in, but we do not see it com eout) unfortunately all efforts to reproduce this on non-hudson trunk have failed. Even trying to reproduce by running on hudson host itself (manually) has failed. We need to instrument the client session creation code in the test to dump the thread stack if the session creation fails. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-597) ASyncHammerTest is failing intermittently on hudson trunk
[ https://issues.apache.org/jira/browse/ZOOKEEPER-597?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Reed updated ZOOKEEPER-597: Attachment: ZOOKEEPER-597_3.patch this installs an uncaught exception handler for all threads. ASyncHammerTest is failing intermittently on hudson trunk - Key: ZOOKEEPER-597 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-597 Project: Zookeeper Issue Type: Bug Components: tests Reporter: Patrick Hunt Assignee: Benjamin Reed Priority: Critical Fix For: 3.3.0 Attachments: ZOOKEEPER-597.patch, ZOOKEEPER-597.patch, ZOOKEEPER-597.patch, ZOOKEEPER-597_2.patch, ZOOKEEPER-597_3.patch ASyncHammerTest is failing intermittently on hudson trunk. There is no clear reason why this is happening, but it seems from the logs that a session connection to a follower is failing during session establishment - the failure seems to be a problem either on the follower or leader. The server gets the session create request, but it stalls in the request processor pipeline. (we see it go in, but we do not see it com eout) unfortunately all efforts to reproduce this on non-hudson trunk have failed. Even trying to reproduce by running on hudson host itself (manually) has failed. We need to instrument the client session creation code in the test to dump the thread stack if the session creation fails. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-597) ASyncHammerTest is failing intermittently on hudson trunk
[ https://issues.apache.org/jira/browse/ZOOKEEPER-597?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Reed updated ZOOKEEPER-597: Attachment: ZOOKEEPER-597_3.patch this patch removes the deadlock and the useless flag that was causing the deadlock and installs a default uncaught exception handler. ASyncHammerTest is failing intermittently on hudson trunk - Key: ZOOKEEPER-597 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-597 Project: Zookeeper Issue Type: Bug Components: tests Reporter: Patrick Hunt Assignee: Benjamin Reed Priority: Critical Fix For: 3.3.0 Attachments: ZOOKEEPER-597.patch, ZOOKEEPER-597.patch, ZOOKEEPER-597.patch, ZOOKEEPER-597_2.patch, ZOOKEEPER-597_3.patch, ZOOKEEPER-597_3.patch ASyncHammerTest is failing intermittently on hudson trunk. There is no clear reason why this is happening, but it seems from the logs that a session connection to a follower is failing during session establishment - the failure seems to be a problem either on the follower or leader. The server gets the session create request, but it stalls in the request processor pipeline. (we see it go in, but we do not see it com eout) unfortunately all efforts to reproduce this on non-hudson trunk have failed. Even trying to reproduce by running on hudson host itself (manually) has failed. We need to instrument the client session creation code in the test to dump the thread stack if the session creation fails. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-602) log all exceptions not caught by ZK threads
[ https://issues.apache.org/jira/browse/ZOOKEEPER-602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12786095#action_12786095 ] Benjamin Reed commented on ZOOKEEPER-602: - i think the best strategy to address this would be to create a ZooKeeperThread that all the code must use with the following properties: 1) it has a single constructor ZooKeeperThread(String threadName, long sid, boolean isUnhandledExceptionFatal), where threadName is a descriptive string, sid is the server id or -1 if not relevant, 2) exceptions will be logged as errors unless isUnhandledExceptionFatal is true, then an unhandle exception on that thread will be logged as fatal and cause a shutdown. log all exceptions not caught by ZK threads --- Key: ZOOKEEPER-602 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-602 Project: Zookeeper Issue Type: Bug Components: java client, server Affects Versions: 3.2.1 Reporter: Patrick Hunt Priority: Critical Fix For: 3.3.0 the java code should add a ThreadGroup exception handler that logs at ERROR level any uncaught exceptions thrown by Thread run methods. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-597) ASyncHammerTest is failing intermittently on hudson trunk
[ https://issues.apache.org/jira/browse/ZOOKEEPER-597?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12786245#action_12786245 ] Benjamin Reed commented on ZOOKEEPER-597: - +1 looks great ASyncHammerTest is failing intermittently on hudson trunk - Key: ZOOKEEPER-597 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-597 Project: Zookeeper Issue Type: Bug Components: tests Reporter: Patrick Hunt Assignee: Benjamin Reed Priority: Critical Fix For: 3.3.0 Attachments: ZOOKEEPER-597.patch, ZOOKEEPER-597.patch, ZOOKEEPER-597.patch, ZOOKEEPER-597_2.patch, ZOOKEEPER-597_3.patch, ZOOKEEPER-597_3.patch, ZOOKEEPER-597_4.patch ASyncHammerTest is failing intermittently on hudson trunk. There is no clear reason why this is happening, but it seems from the logs that a session connection to a follower is failing during session establishment - the failure seems to be a problem either on the follower or leader. The server gets the session create request, but it stalls in the request processor pipeline. (we see it go in, but we do not see it com eout) unfortunately all efforts to reproduce this on non-hudson trunk have failed. Even trying to reproduce by running on hudson host itself (manually) has failed. We need to instrument the client session creation code in the test to dump the thread stack if the session creation fails. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-611) hudson build failiure
[ https://issues.apache.org/jira/browse/ZOOKEEPER-611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12787164#action_12787164 ] Benjamin Reed commented on ZOOKEEPER-611: - we should probably check if that property is set before overwriting it we should probably also have a comment pointing out that this is a work around for the sun bug (and point to the bug) hudson build failiure - Key: ZOOKEEPER-611 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-611 Project: Zookeeper Issue Type: Bug Reporter: Mahadev konar Assignee: Mahadev konar Fix For: 3.3.0 Attachments: ZOOKEEPER-611.patch The hudson build failure failed again on http://hudson.zones.apache.org/hudson/job/ZooKeeper-trunk/582/ -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-611) hudson build failiure
[ https://issues.apache.org/jira/browse/ZOOKEEPER-611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12787166#action_12787166 ] Benjamin Reed commented on ZOOKEEPER-611: - scratch the point to the bug part. it is already there. hudson build failiure - Key: ZOOKEEPER-611 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-611 Project: Zookeeper Issue Type: Bug Reporter: Mahadev konar Assignee: Mahadev konar Fix For: 3.3.0 Attachments: ZOOKEEPER-611.patch The hudson build failure failed again on http://hudson.zones.apache.org/hudson/job/ZooKeeper-trunk/582/ -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-611) hudson build failiure
[ https://issues.apache.org/jira/browse/ZOOKEEPER-611?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Reed updated ZOOKEEPER-611: Hadoop Flags: [Reviewed] +1 hudson build failiure - Key: ZOOKEEPER-611 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-611 Project: Zookeeper Issue Type: Bug Reporter: Mahadev konar Assignee: Mahadev konar Fix For: 3.3.0 Attachments: ZOOKEEPER-611.patch, ZOOKEEPER-611.patch The hudson build failure failed again on http://hudson.zones.apache.org/hudson/job/ZooKeeper-trunk/582/ -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-597) ASyncHammerTest is failing intermittently on hudson trunk
[ https://issues.apache.org/jira/browse/ZOOKEEPER-597?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12787665#action_12787665 ] Benjamin Reed commented on ZOOKEEPER-597: - +1 for 3.1 and 3.2 ASyncHammerTest is failing intermittently on hudson trunk - Key: ZOOKEEPER-597 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-597 Project: Zookeeper Issue Type: Bug Components: tests Reporter: Patrick Hunt Assignee: Benjamin Reed Priority: Critical Fix For: 3.3.0 Attachments: ZOOKEEPER-597-3.1.patch, ZOOKEEPER-597-3.2.patch, ZOOKEEPER-597.patch, ZOOKEEPER-597.patch, ZOOKEEPER-597.patch, ZOOKEEPER-597_2.patch, ZOOKEEPER-597_3.patch, ZOOKEEPER-597_3.patch, ZOOKEEPER-597_4.patch ASyncHammerTest is failing intermittently on hudson trunk. There is no clear reason why this is happening, but it seems from the logs that a session connection to a follower is failing during session establishment - the failure seems to be a problem either on the follower or leader. The server gets the session create request, but it stalls in the request processor pipeline. (we see it go in, but we do not see it com eout) unfortunately all efforts to reproduce this on non-hudson trunk have failed. Even trying to reproduce by running on hudson host itself (manually) has failed. We need to instrument the client session creation code in the test to dump the thread stack if the session creation fails. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-611) hudson build failiure
[ https://issues.apache.org/jira/browse/ZOOKEEPER-611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12787697#action_12787697 ] Benjamin Reed commented on ZOOKEEPER-611: - +1 looks good hudson build failiure - Key: ZOOKEEPER-611 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-611 Project: Zookeeper Issue Type: Bug Reporter: Mahadev konar Assignee: Mahadev konar Fix For: 3.3.0 Attachments: ZOOKEEPER-611-3.1.patch, ZOOKEEPER-611-3.2.patch, ZOOKEEPER-611.patch, ZOOKEEPER-611.patch, ZOOKEEPER-611.patch The hudson build failure failed again on http://hudson.zones.apache.org/hudson/job/ZooKeeper-trunk/582/ -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-599) Changes to FLE and QuorumCnxManager to support Observers
[
https://issues.apache.org/jira/browse/ZOOKEEPER-599?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12789392#action_12789392
]
Benjamin Reed commented on ZOOKEEPER-599:
-
looks good flavio. i'd like to request two changes:
1) can you remove or expand debug message so that they are more informative?
for example, if(recvqueue.size() == 0) LOG.debug(Message: + n.sid);
doesn't describe what is going on or why the message is being logged.
2) can we simplify:
+Random r = new Random();
+do{
+sid = 1L + ((long) r.nextInt(1));
+} while(self.getVotingView().containsKey(sid)
+|| senderWorkerMap.containsKey(sid));
if we guarantee that followers are non-negative, we could pick negative sids
for observers, so that we don't have to worry about observers colliding with
follower sids. it might also help later for debugging.
Changes to FLE and QuorumCnxManager to support Observers
Key: ZOOKEEPER-599
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-599
Project: Zookeeper
Issue Type: Improvement
Reporter: Flavio Paiva Junqueira
Assignee: Flavio Paiva Junqueira
Fix For: 3.3.0
Attachments: ZOOKEEPER-599.patch, ZOOKEEPER-599.patch,
ZOOKEEPER-599.patch
Observers currently can only use electionAlg 0, which is not the default,
supported leader implementation. This issue will fix it.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-615) wrong javadoc for create with a sequence flag
[ https://issues.apache.org/jira/browse/ZOOKEEPER-615?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Reed updated ZOOKEEPER-615: Resolution: Fixed Status: Resolved (was: Patch Available) wrong javadoc for create with a sequence flag - Key: ZOOKEEPER-615 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-615 Project: Zookeeper Issue Type: Bug Reporter: Mahadev konar Assignee: Mahadev konar Fix For: 3.3.0 Attachments: ZOOKEEPER-615.patch The javadoc for create with a sequence flag mentions a suffix of \_i but the true suffix is just i and no \_. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-615) wrong javadoc for create with a sequence flag
[ https://issues.apache.org/jira/browse/ZOOKEEPER-615?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12789485#action_12789485 ] Benjamin Reed commented on ZOOKEEPER-615: - Committed revision 889780. wrong javadoc for create with a sequence flag - Key: ZOOKEEPER-615 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-615 Project: Zookeeper Issue Type: Bug Reporter: Mahadev konar Assignee: Mahadev konar Fix For: 3.3.0 Attachments: ZOOKEEPER-615.patch The javadoc for create with a sequence flag mentions a suffix of \_i but the true suffix is just i and no \_. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-486) Improve bookie performance for large number of ledgers
[ https://issues.apache.org/jira/browse/ZOOKEEPER-486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Reed updated ZOOKEEPER-486: Attachment: ZOOKEEPER-486.patch fixed the check for no lodger in bookie.java Improve bookie performance for large number of ledgers -- Key: ZOOKEEPER-486 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-486 Project: Zookeeper Issue Type: Improvement Components: contrib-bookkeeper Reporter: Flavio Paiva Junqueira Assignee: Benjamin Reed Attachments: ZOOKEEPER-486.patch, ZOOKEEPER-486.patch If we write simultaneously to a large number of ledgers on a bookie, then performance drops significantly due to more seeks on the ledger device. In such cases, we should be clustering ledgers into files to reduce the number of seeks, and performing sequential writes on each file. Clustering ledgers will impact read performance, so we would to have a knob to control such a feature. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-486) Improve bookie performance for large number of ledgers
[ https://issues.apache.org/jira/browse/ZOOKEEPER-486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Reed updated ZOOKEEPER-486: Status: Patch Available (was: Open) Improve bookie performance for large number of ledgers -- Key: ZOOKEEPER-486 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-486 Project: Zookeeper Issue Type: Improvement Components: contrib-bookkeeper Reporter: Flavio Paiva Junqueira Assignee: Benjamin Reed Attachments: ZOOKEEPER-486.patch, ZOOKEEPER-486.patch If we write simultaneously to a large number of ledgers on a bookie, then performance drops significantly due to more seeks on the ledger device. In such cases, we should be clustering ledgers into files to reduce the number of seeks, and performing sequential writes on each file. Clustering ledgers will impact read performance, so we would to have a knob to control such a feature. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (ZOOKEEPER-506) QuorumBase should use default leader election
[ https://issues.apache.org/jira/browse/ZOOKEEPER-506?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Reed resolved ZOOKEEPER-506. - Resolution: Fixed Committed revision 891034. QuorumBase should use default leader election - Key: ZOOKEEPER-506 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-506 Project: Zookeeper Issue Type: Improvement Components: leaderElection Reporter: Flavio Paiva Junqueira Assignee: Flavio Paiva Junqueira Fix For: 3.3.0 QuorumBase currently does not use the default implementation of leader election. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-486) Improve bookie performance for large number of ledgers
[ https://issues.apache.org/jira/browse/ZOOKEEPER-486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Reed updated ZOOKEEPER-486: Attachment: ZOOKEEPER-486.patch added comments Improve bookie performance for large number of ledgers -- Key: ZOOKEEPER-486 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-486 Project: Zookeeper Issue Type: Improvement Components: contrib-bookkeeper Reporter: Flavio Paiva Junqueira Assignee: Benjamin Reed Attachments: ZOOKEEPER-486.patch, ZOOKEEPER-486.patch, ZOOKEEPER-486.patch If we write simultaneously to a large number of ledgers on a bookie, then performance drops significantly due to more seeks on the ledger device. In such cases, we should be clustering ledgers into files to reduce the number of seeks, and performing sequential writes on each file. Clustering ledgers will impact read performance, so we would to have a knob to control such a feature. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-486) Improve bookie performance for large number of ledgers
[ https://issues.apache.org/jira/browse/ZOOKEEPER-486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Reed updated ZOOKEEPER-486: Attachment: ZOOKEEPER-486.patch added the missing files. Improve bookie performance for large number of ledgers -- Key: ZOOKEEPER-486 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-486 Project: Zookeeper Issue Type: Improvement Components: contrib-bookkeeper Reporter: Flavio Paiva Junqueira Assignee: Benjamin Reed Attachments: ZOOKEEPER-486.patch, ZOOKEEPER-486.patch, ZOOKEEPER-486.patch, ZOOKEEPER-486.patch If we write simultaneously to a large number of ledgers on a bookie, then performance drops significantly due to more seeks on the ledger device. In such cases, we should be clustering ledgers into files to reduce the number of seeks, and performing sequential writes on each file. Clustering ledgers will impact read performance, so we would to have a knob to control such a feature. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-486) Improve bookie performance for large number of ledgers
[ https://issues.apache.org/jira/browse/ZOOKEEPER-486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Reed updated ZOOKEEPER-486: Attachment: ZOOKEEPER-486.patch the patch was rooted in bookkeeper rather than the top. Improve bookie performance for large number of ledgers -- Key: ZOOKEEPER-486 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-486 Project: Zookeeper Issue Type: Improvement Components: contrib-bookkeeper Reporter: Flavio Paiva Junqueira Assignee: Benjamin Reed Attachments: ZOOKEEPER-486.patch, ZOOKEEPER-486.patch, ZOOKEEPER-486.patch, ZOOKEEPER-486.patch, ZOOKEEPER-486.patch If we write simultaneously to a large number of ledgers on a bookie, then performance drops significantly due to more seeks on the ledger device. In such cases, we should be clustering ledgers into files to reduce the number of seeks, and performing sequential writes on each file. Clustering ledgers will impact read performance, so we would to have a knob to control such a feature. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (ZOOKEEPER-623) ClientBase in bookkeeper.util requires junit
[ https://issues.apache.org/jira/browse/ZOOKEEPER-623?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Reed resolved ZOOKEEPER-623. - Resolution: Fixed Hadoop Flags: [Reviewed] Committed revision 891809. ClientBase in bookkeeper.util requires junit Key: ZOOKEEPER-623 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-623 Project: Zookeeper Issue Type: Bug Components: contrib-bookkeeper Reporter: Flavio Paiva Junqueira Assignee: Flavio Paiva Junqueira Fix For: 3.3.0 Attachments: ZOOKEEPER-623.patch, ZOOKEEPER-623.patch Class org.apache.bookkeeper.util.ClientBase requires junit, and when I tried to just compile bookkeeper, no test, with the patch of ZOOKEEPER-534, compilation failed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-623) ClientBase in bookkeeper.util requires junit
[ https://issues.apache.org/jira/browse/ZOOKEEPER-623?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Reed updated ZOOKEEPER-623: Attachment: ZOOKEEPER-623_2.patch makes bookkeeper tests work again. ClientBase in bookkeeper.util requires junit Key: ZOOKEEPER-623 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-623 Project: Zookeeper Issue Type: Bug Components: contrib-bookkeeper Reporter: Flavio Paiva Junqueira Assignee: Flavio Paiva Junqueira Fix For: 3.3.0 Attachments: ZOOKEEPER-623.patch, ZOOKEEPER-623.patch, ZOOKEEPER-623_2.patch Class org.apache.bookkeeper.util.ClientBase requires junit, and when I tried to just compile bookkeeper, no test, with the patch of ZOOKEEPER-534, compilation failed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-623) ClientBase in bookkeeper.util requires junit
[ https://issues.apache.org/jira/browse/ZOOKEEPER-623?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Reed updated ZOOKEEPER-623: Attachment: ZOOKEEPER-623_2.patch updated to not try to resolve ClientBase and print a better message. ClientBase in bookkeeper.util requires junit Key: ZOOKEEPER-623 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-623 Project: Zookeeper Issue Type: Bug Components: contrib-bookkeeper Reporter: Flavio Paiva Junqueira Assignee: Flavio Paiva Junqueira Fix For: 3.3.0 Attachments: ZOOKEEPER-623.patch, ZOOKEEPER-623.patch, ZOOKEEPER-623_2.patch, ZOOKEEPER-623_2.patch Class org.apache.bookkeeper.util.ClientBase requires junit, and when I tried to just compile bookkeeper, no test, with the patch of ZOOKEEPER-534, compilation failed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-596) The last logged zxid calculated by zookeeper servers could cause problems in leader election if data gets corrupted.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-596?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12792142#action_12792142 ] Benjamin Reed commented on ZOOKEEPER-596: - +1 (assuming it passes test) The last logged zxid calculated by zookeeper servers could cause problems in leader election if data gets corrupted. Key: ZOOKEEPER-596 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-596 Project: Zookeeper Issue Type: Bug Affects Versions: 3.2.1 Reporter: Mahadev konar Assignee: Mahadev konar Fix For: 3.3.0 Attachments: ZOOKEEPER-596.patch, ZOOKEEPER-596.patch, ZOOKEEPER-596.patch, ZOOKEEPER-596.patch, ZOOKEEPER-596.patch, ZOOKEEPER-596.patch It is possible that the last loggged zxid as reported by all the servers during leader election is not the last zxid that the server can upload data to. It is very much possible that some transaction or snapshot gets corrupted and the servers actually do not have valid data till last logged zxid. We need to make sure that what the servers report as there last logged zxid, they are able to load data till that zxid. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-426) Windows versions of zookeeper scripts
[ https://issues.apache.org/jira/browse/ZOOKEEPER-426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12792150#action_12792150 ] Benjamin Reed commented on ZOOKEEPER-426: - the plan is to put all of these files in bin and svn add them correct? Windows versions of zookeeper scripts - Key: ZOOKEEPER-426 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-426 Project: Zookeeper Issue Type: Improvement Components: scripts Affects Versions: 3.1.1 Reporter: David Bosschaert Assignee: David Bosschaert Fix For: 3.3.0 Attachments: README.txt, zkCli.cmd, zkCli.cmd, zkEnv.cmd, zkEnv.cmd, zkServer.cmd, zkServer.cmd Attached are a some Windows versions of the zookeeper scripts. They aren't as powerful as the .sh ones but they do work for me and can be invoked with any directory as the current dir. The biggest trick in the scripts is in the zkEnv.cmd one where it says: set ZOOCFGDIR=%~dp0%..\conf this basically figures out the location of the zkEnv.cmd file and sets the conf directory relative to that. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-606) bin scripts don't work in cygwin (spaces in paths)
[ https://issues.apache.org/jira/browse/ZOOKEEPER-606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12792153#action_12792153 ] Benjamin Reed commented on ZOOKEEPER-606: - +1 bin scripts don't work in cygwin (spaces in paths) -- Key: ZOOKEEPER-606 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-606 Project: Zookeeper Issue Type: Bug Components: scripts Affects Versions: 3.2.1 Reporter: Patrick Hunt Assignee: Patrick Hunt Fix For: 3.3.0 Attachments: ZOOKEEPER-606.patch, ZOOKEEPER-606.patch the scripts in bin fail under cygwin due to spaces not handled properly -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-606) bin scripts don't work in cygwin (spaces in paths)
[ https://issues.apache.org/jira/browse/ZOOKEEPER-606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Reed updated ZOOKEEPER-606: Resolution: Fixed Release Note: Committed revision 891944. Hadoop Flags: [Reviewed] Status: Resolved (was: Patch Available) bin scripts don't work in cygwin (spaces in paths) -- Key: ZOOKEEPER-606 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-606 Project: Zookeeper Issue Type: Bug Components: scripts Affects Versions: 3.2.1 Reporter: Patrick Hunt Assignee: Patrick Hunt Fix For: 3.3.0 Attachments: ZOOKEEPER-606.patch, ZOOKEEPER-606.patch the scripts in bin fail under cygwin due to spaces not handled properly -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-507) BookKeeper client re-write
[ https://issues.apache.org/jira/browse/ZOOKEEPER-507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12795351#action_12795351 ] Benjamin Reed commented on ZOOKEEPER-507: - it turns out that the BookieFailureTest was failing due to a bug in netty. it appears to have been fixed at the end of september (see http://viewvc.jboss.org/cgi-bin/viewvc.cgi/netty/trunk/src/main/java/org/jboss/netty/channel/socket/nio/NioWorker.java?view=log) . the fix is in 3.1.5. Running with netty 3.1.5 allows all the tests to pass. BookKeeper client re-write -- Key: ZOOKEEPER-507 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-507 Project: Zookeeper Issue Type: Improvement Components: contrib-bookkeeper Reporter: Flavio Paiva Junqueira Assignee: Utkarsh Srivastava Attachments: BookieFailureTest-log-507.rtf, ZOOKEEPER-507.patch, ZOOKEEPER-507.patch, ZOOKEEPER-507.patch Error handling is far from ideal currently in the BookKeeper client. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-633) Fetch netty using ivy for bookkeeper
[
https://issues.apache.org/jira/browse/ZOOKEEPER-633?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Reed updated ZOOKEEPER-633:
Attachment: zookeeper-633.patch
thanx giri! one small correction. netty has a type of bundle rather than
jar. (i'm not sure of the distinction, but i had to add a line to the
ivy-retrieve to handle it.
Fetch netty using ivy for bookkeeper
Key: ZOOKEEPER-633
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-633
Project: Zookeeper
Issue Type: Improvement
Components: contrib-bookkeeper
Reporter: Flavio Paiva Junqueira
Assignee: Giridharan Kesavan
Fix For: 3.3.0
Attachments: zookeeper-633.patch, zookeeper-633.patch
The patch of ZOOKEEPER-507 requires netty and to compile we now have to
manually add the netty jar to {project root}/src/java/lib. GIven that we
bookkeeper already fetches junit and log4j using ivy, we could also do it for
netty. However, we need to configure it to fetch from a different repository.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-496) zookeeper-tree utility for export, import and incremental updates
[ https://issues.apache.org/jira/browse/ZOOKEEPER-496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Reed updated ZOOKEEPER-496: Status: Open (was: Patch Available) zookeeper-tree utility for export, import and incremental updates - Key: ZOOKEEPER-496 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-496 Project: Zookeeper Issue Type: New Feature Components: contrib Environment: RHEL 4.6, libxml2 Reporter: Anirban Roy Assignee: Anirban Roy Fix For: 3.3.0 Attachments: zktreeutil.patch Original Estimate: 168h Remaining Estimate: 168h == zktreeutil - Zookeeper Tree Data Utility Author: Anirban Roy Organization: Yahoo Inc. == zktreeutil program is intended to manage and manipulate zk-tree data quickly, effi- ciently and with ease. The utility operates on free-form ZK-tree and hence can be used for any cluster managed by Zookeeper. Here are the basic functionalities - EXPORT: The whole/partial ZK-tree is exported into a XML file. This helps in capturing a current snapshot of the data for backup/analysis. For a subtree export, one need to specify the path to the ZK-subtree with proper option. IMPORT: The ZK-tree can be imported from XML into ZK cluster. This helps in priming the new ZK cluster with static configuration. The import can be non-intrusive by making only the additions in the existing data. The import of subtree is also possible by optionally providing the path to the ZK-subtree. DIFF: Creates a diff between live ZK data vs data saved in XML file. Diff can ignore some ZK-tree branches (possibly dynamic data) on reading the optional ignore flag from XML file. Diffing on a ZK-subtree achieved by providing path to ZK-subtree with diff command. UPDATE: Make the incremental changes into the live ZK-tree from saved XML, essentia- lly after running the diff. DUMP: Dumps the ZK-tree on the standard output device reading either from live ZK server or XML file. Like export, ZK-subtree can be dumped with optionaly providing the path to the ZK-subtree, and till a certain depth of the (sub)tree. The exported ZK data into XML file can be shortened by only keeping the static ZK nodes which are required to prime a cluster. The dynamic zk nodes (created on-the- fly) can be ignored by setting a 'ignore' attribute at the root node of the dynamic subtree (see tests/zk_sample.xml), possibly deleting all inner ZK nodes under that. Once ignored, the whole subtree is ignored during DIFF, UPDATE and WRITE. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-544) improve client testability - allow test client to access connected server location
[ https://issues.apache.org/jira/browse/ZOOKEEPER-544?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Reed updated ZOOKEEPER-544: Resolution: Fixed Hadoop Flags: [Reviewed] Status: Resolved (was: Patch Available) Committed revision 896143. improve client testability - allow test client to access connected server location -- Key: ZOOKEEPER-544 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-544 Project: Zookeeper Issue Type: Improvement Components: c client, java client, tests Reporter: Patrick Hunt Assignee: Patrick Hunt Fix For: 3.3.0 Attachments: ZOOKEEPER-544.patch, ZOOKEEPER-544.patch, ZOOKEEPER-544.patch This came up recently on the user list. If you are developing tests for your zk client you need to be able to access the server that your session is currently connected to. The reason is that your test needs to know which server in the quorum to shutdown in order to verify you are handling failover correctly. Similar for session expiration testing. however we should be careful, we prefer not to expose this to all clients, this is an implementation detail that we typically want to hide. also we should provide this in both the c and java clients I suspect we should add a protected method on ZooKeeper. This will make a higher bar (user will have to subclass) for the user to access this method. In tests it's fine, typically you want a TestableZooKeeper class anyway. In c we unfortunately have less options, we can just rely on docs for now. In both cases (c/java) we need to be very very clear in the docs that this is for testing only and to clearly define semantics. We should add the following at the same time: toString() method to ZooKeeper which includes server ip/port, client port, any other information deemed useful (connection stats like send/recv?) the java ZooKeeper is missing deterministic connection order that the c client has. this is also useful for testing. again, protected and clear docs that this is for testing purposes only! Any other things we should expose? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-426) Windows versions of zookeeper scripts
[ https://issues.apache.org/jira/browse/ZOOKEEPER-426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Reed updated ZOOKEEPER-426: Resolution: Fixed Hadoop Flags: [Reviewed] Status: Resolved (was: Patch Available) Committed revision 896144. thanx david! Windows versions of zookeeper scripts - Key: ZOOKEEPER-426 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-426 Project: Zookeeper Issue Type: Improvement Components: scripts Affects Versions: 3.1.1 Reporter: David Bosschaert Assignee: David Bosschaert Fix For: 3.3.0 Attachments: README.txt, zkCli.cmd, zkCli.cmd, zkEnv.cmd, zkEnv.cmd, zkServer.cmd, zkServer.cmd Attached are a some Windows versions of the zookeeper scripts. They aren't as powerful as the .sh ones but they do work for me and can be invoked with any directory as the current dir. The biggest trick in the scripts is in the zkEnv.cmd one where it says: set ZOOCFGDIR=%~dp0%..\conf this basically figures out the location of the zkEnv.cmd file and sets the conf directory relative to that. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-612) Make Zookeeper C client can be compiled by gcc of early version
[ https://issues.apache.org/jira/browse/ZOOKEEPER-612?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12796785#action_12796785 ] Benjamin Reed commented on ZOOKEEPER-612: - this looks good except for one piece of code: -hints.ai_flags = AI_ADDRCONFIG; +//hints.ai_flags = AI_ADDRCONFIG; +hints.ai_flags = 0; why do you remove AI_ADDRCONFIG? Make Zookeeper C client can be compiled by gcc of early version --- Key: ZOOKEEPER-612 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-612 Project: Zookeeper Issue Type: Improvement Components: c client Affects Versions: 3.2.1 Environment: Linux Reporter: Qian Ye Attachments: patch, patch The original C Client, Version 3.2.1, cannot be compiled successfully by the gcc of early version, due some declaration restriction. To compile the source code on the server with gcc of early version, I made some modification on the original source. What's more, some extra codes are added to make the client be compatible with the hosts list format: ip1:port1, ip2:port2... There is often a space after this kind of comma. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-637) Trunk build is failing
[ https://issues.apache.org/jira/browse/ZOOKEEPER-637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12797172#action_12797172 ] Benjamin Reed commented on ZOOKEEPER-637: - it is also failing on 1.7.1. (i just wasn't letting it run long enough when i first tried it.) Trunk build is failing -- Key: ZOOKEEPER-637 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-637 Project: Zookeeper Issue Type: Bug Components: build Reporter: Flavio Paiva Junqueira Assignee: Flavio Paiva Junqueira The trunk build is failing when Hudson runs it. The problem seems to be that ivy-init is executed only once, but its definitions (in particular ivy:settings) do not persist, and the failure occurs when we run ivy-retrieve a second time, which requires the definition of ivy:settings. It seems that the problem occur with ant 1.7.0, but not with 1.7.1, so it could be an ant issue. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-637) Trunk build is failing
[ https://issues.apache.org/jira/browse/ZOOKEEPER-637?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Reed updated ZOOKEEPER-637: Resolution: Fixed Status: Resolved (was: Patch Available) Committed revision 896551. Trunk build is failing -- Key: ZOOKEEPER-637 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-637 Project: Zookeeper Issue Type: Bug Components: build Reporter: Flavio Paiva Junqueira Assignee: Flavio Paiva Junqueira Attachments: ZOOKEEPER-637.patch The trunk build is failing when Hudson runs it. The problem seems to be that ivy-init is executed only once, but its definitions (in particular ivy:settings) do not persist, and the failure occurs when we run ivy-retrieve a second time, which requires the definition of ivy:settings. It seems that the problem occur with ant 1.7.0, but not with 1.7.1, so it could be an ant issue. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-496) zookeeper-tree utility for export, import and incremental updates
[ https://issues.apache.org/jira/browse/ZOOKEEPER-496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Reed updated ZOOKEEPER-496: Status: Patch Available (was: Open) zookeeper-tree utility for export, import and incremental updates - Key: ZOOKEEPER-496 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-496 Project: Zookeeper Issue Type: New Feature Components: contrib Environment: RHEL 4.6, libxml2 Reporter: Anirban Roy Assignee: Anirban Roy Fix For: 3.3.0 Attachments: zktreeutil.patch Original Estimate: 168h Remaining Estimate: 168h == zktreeutil - Zookeeper Tree Data Utility Author: Anirban Roy Organization: Yahoo Inc. == zktreeutil program is intended to manage and manipulate zk-tree data quickly, effi- ciently and with ease. The utility operates on free-form ZK-tree and hence can be used for any cluster managed by Zookeeper. Here are the basic functionalities - EXPORT: The whole/partial ZK-tree is exported into a XML file. This helps in capturing a current snapshot of the data for backup/analysis. For a subtree export, one need to specify the path to the ZK-subtree with proper option. IMPORT: The ZK-tree can be imported from XML into ZK cluster. This helps in priming the new ZK cluster with static configuration. The import can be non-intrusive by making only the additions in the existing data. The import of subtree is also possible by optionally providing the path to the ZK-subtree. DIFF: Creates a diff between live ZK data vs data saved in XML file. Diff can ignore some ZK-tree branches (possibly dynamic data) on reading the optional ignore flag from XML file. Diffing on a ZK-subtree achieved by providing path to ZK-subtree with diff command. UPDATE: Make the incremental changes into the live ZK-tree from saved XML, essentia- lly after running the diff. DUMP: Dumps the ZK-tree on the standard output device reading either from live ZK server or XML file. Like export, ZK-subtree can be dumped with optionaly providing the path to the ZK-subtree, and till a certain depth of the (sub)tree. The exported ZK data into XML file can be shortened by only keeping the static ZK nodes which are required to prime a cluster. The dynamic zk nodes (created on-the- fly) can be ignored by setting a 'ignore' attribute at the root node of the dynamic subtree (see tests/zk_sample.xml), possibly deleting all inner ZK nodes under that. Once ignored, the whole subtree is ignored during DIFF, UPDATE and WRITE. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-496) zookeeper-tree utility for export, import and incremental updates
[ https://issues.apache.org/jira/browse/ZOOKEEPER-496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Reed updated ZOOKEEPER-496: Status: Open (was: Patch Available) zookeeper-tree utility for export, import and incremental updates - Key: ZOOKEEPER-496 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-496 Project: Zookeeper Issue Type: New Feature Components: contrib Environment: RHEL 4.6, libxml2 Reporter: Anirban Roy Assignee: Anirban Roy Fix For: 3.3.0 Attachments: zktreeutil.patch Original Estimate: 168h Remaining Estimate: 168h == zktreeutil - Zookeeper Tree Data Utility Author: Anirban Roy Organization: Yahoo Inc. == zktreeutil program is intended to manage and manipulate zk-tree data quickly, effi- ciently and with ease. The utility operates on free-form ZK-tree and hence can be used for any cluster managed by Zookeeper. Here are the basic functionalities - EXPORT: The whole/partial ZK-tree is exported into a XML file. This helps in capturing a current snapshot of the data for backup/analysis. For a subtree export, one need to specify the path to the ZK-subtree with proper option. IMPORT: The ZK-tree can be imported from XML into ZK cluster. This helps in priming the new ZK cluster with static configuration. The import can be non-intrusive by making only the additions in the existing data. The import of subtree is also possible by optionally providing the path to the ZK-subtree. DIFF: Creates a diff between live ZK data vs data saved in XML file. Diff can ignore some ZK-tree branches (possibly dynamic data) on reading the optional ignore flag from XML file. Diffing on a ZK-subtree achieved by providing path to ZK-subtree with diff command. UPDATE: Make the incremental changes into the live ZK-tree from saved XML, essentia- lly after running the diff. DUMP: Dumps the ZK-tree on the standard output device reading either from live ZK server or XML file. Like export, ZK-subtree can be dumped with optionaly providing the path to the ZK-subtree, and till a certain depth of the (sub)tree. The exported ZK data into XML file can be shortened by only keeping the static ZK nodes which are required to prime a cluster. The dynamic zk nodes (created on-the- fly) can be ignored by setting a 'ignore' attribute at the root node of the dynamic subtree (see tests/zk_sample.xml), possibly deleting all inner ZK nodes under that. Once ignored, the whole subtree is ignored during DIFF, UPDATE and WRITE. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-637) Trunk build is failing
[ https://issues.apache.org/jira/browse/ZOOKEEPER-637?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Reed updated ZOOKEEPER-637: Status: Patch Available (was: Reopened) Trunk build is failing -- Key: ZOOKEEPER-637 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-637 Project: Zookeeper Issue Type: Bug Components: build Reporter: Flavio Paiva Junqueira Assignee: Flavio Paiva Junqueira Attachments: ZOOKEEPER-632_2.patch, ZOOKEEPER-637.patch The trunk build is failing when Hudson runs it. The problem seems to be that ivy-init is executed only once, but its definitions (in particular ivy:settings) do not persist, and the failure occurs when we run ivy-retrieve a second time, which requires the definition of ivy:settings. It seems that the problem occur with ant 1.7.0, but not with 1.7.1, so it could be an ant issue. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-637) Trunk build is failing
[ https://issues.apache.org/jira/browse/ZOOKEEPER-637?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Reed updated ZOOKEEPER-637: Attachment: ZOOKEEPER-632_2.patch makes sure that taskdef is only run once. Trunk build is failing -- Key: ZOOKEEPER-637 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-637 Project: Zookeeper Issue Type: Bug Components: build Reporter: Flavio Paiva Junqueira Assignee: Flavio Paiva Junqueira Attachments: ZOOKEEPER-632_2.patch, ZOOKEEPER-637.patch The trunk build is failing when Hudson runs it. The problem seems to be that ivy-init is executed only once, but its definitions (in particular ivy:settings) do not persist, and the failure occurs when we run ivy-retrieve a second time, which requires the definition of ivy:settings. It seems that the problem occur with ant 1.7.0, but not with 1.7.1, so it could be an ant issue. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-496) zookeeper-tree utility for export, import and incremental updates
[ https://issues.apache.org/jira/browse/ZOOKEEPER-496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Reed updated ZOOKEEPER-496: Status: Open (was: Patch Available) zookeeper-tree utility for export, import and incremental updates - Key: ZOOKEEPER-496 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-496 Project: Zookeeper Issue Type: New Feature Components: contrib Environment: RHEL 4.6, libxml2 Reporter: Anirban Roy Assignee: Anirban Roy Fix For: 3.3.0 Attachments: zktreeutil.patch Original Estimate: 168h Remaining Estimate: 168h == zktreeutil - Zookeeper Tree Data Utility Author: Anirban Roy Organization: Yahoo Inc. == zktreeutil program is intended to manage and manipulate zk-tree data quickly, effi- ciently and with ease. The utility operates on free-form ZK-tree and hence can be used for any cluster managed by Zookeeper. Here are the basic functionalities - EXPORT: The whole/partial ZK-tree is exported into a XML file. This helps in capturing a current snapshot of the data for backup/analysis. For a subtree export, one need to specify the path to the ZK-subtree with proper option. IMPORT: The ZK-tree can be imported from XML into ZK cluster. This helps in priming the new ZK cluster with static configuration. The import can be non-intrusive by making only the additions in the existing data. The import of subtree is also possible by optionally providing the path to the ZK-subtree. DIFF: Creates a diff between live ZK data vs data saved in XML file. Diff can ignore some ZK-tree branches (possibly dynamic data) on reading the optional ignore flag from XML file. Diffing on a ZK-subtree achieved by providing path to ZK-subtree with diff command. UPDATE: Make the incremental changes into the live ZK-tree from saved XML, essentia- lly after running the diff. DUMP: Dumps the ZK-tree on the standard output device reading either from live ZK server or XML file. Like export, ZK-subtree can be dumped with optionaly providing the path to the ZK-subtree, and till a certain depth of the (sub)tree. The exported ZK data into XML file can be shortened by only keeping the static ZK nodes which are required to prime a cluster. The dynamic zk nodes (created on-the- fly) can be ignored by setting a 'ignore' attribute at the root node of the dynamic subtree (see tests/zk_sample.xml), possibly deleting all inner ZK nodes under that. Once ignored, the whole subtree is ignored during DIFF, UPDATE and WRITE. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-496) zookeeper-tree utility for export, import and incremental updates
[ https://issues.apache.org/jira/browse/ZOOKEEPER-496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Reed updated ZOOKEEPER-496: Status: Patch Available (was: Open) zookeeper-tree utility for export, import and incremental updates - Key: ZOOKEEPER-496 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-496 Project: Zookeeper Issue Type: New Feature Components: contrib Environment: RHEL 4.6, libxml2 Reporter: Anirban Roy Assignee: Anirban Roy Fix For: 3.3.0 Attachments: zktreeutil.patch Original Estimate: 168h Remaining Estimate: 168h == zktreeutil - Zookeeper Tree Data Utility Author: Anirban Roy Organization: Yahoo Inc. == zktreeutil program is intended to manage and manipulate zk-tree data quickly, effi- ciently and with ease. The utility operates on free-form ZK-tree and hence can be used for any cluster managed by Zookeeper. Here are the basic functionalities - EXPORT: The whole/partial ZK-tree is exported into a XML file. This helps in capturing a current snapshot of the data for backup/analysis. For a subtree export, one need to specify the path to the ZK-subtree with proper option. IMPORT: The ZK-tree can be imported from XML into ZK cluster. This helps in priming the new ZK cluster with static configuration. The import can be non-intrusive by making only the additions in the existing data. The import of subtree is also possible by optionally providing the path to the ZK-subtree. DIFF: Creates a diff between live ZK data vs data saved in XML file. Diff can ignore some ZK-tree branches (possibly dynamic data) on reading the optional ignore flag from XML file. Diffing on a ZK-subtree achieved by providing path to ZK-subtree with diff command. UPDATE: Make the incremental changes into the live ZK-tree from saved XML, essentia- lly after running the diff. DUMP: Dumps the ZK-tree on the standard output device reading either from live ZK server or XML file. Like export, ZK-subtree can be dumped with optionaly providing the path to the ZK-subtree, and till a certain depth of the (sub)tree. The exported ZK data into XML file can be shortened by only keeping the static ZK nodes which are required to prime a cluster. The dynamic zk nodes (created on-the- fly) can be ignored by setting a 'ignore' attribute at the root node of the dynamic subtree (see tests/zk_sample.xml), possibly deleting all inner ZK nodes under that. Once ignored, the whole subtree is ignored during DIFF, UPDATE and WRITE. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-496) zookeeper-tree utility for export, import and incremental updates
[ https://issues.apache.org/jira/browse/ZOOKEEPER-496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Reed updated ZOOKEEPER-496: Status: Open (was: Patch Available) zookeeper-tree utility for export, import and incremental updates - Key: ZOOKEEPER-496 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-496 Project: Zookeeper Issue Type: New Feature Components: contrib Environment: RHEL 4.6, libxml2 Reporter: Anirban Roy Assignee: Anirban Roy Fix For: 3.3.0 Attachments: zktreeutil.patch Original Estimate: 168h Remaining Estimate: 168h == zktreeutil - Zookeeper Tree Data Utility Author: Anirban Roy Organization: Yahoo Inc. == zktreeutil program is intended to manage and manipulate zk-tree data quickly, effi- ciently and with ease. The utility operates on free-form ZK-tree and hence can be used for any cluster managed by Zookeeper. Here are the basic functionalities - EXPORT: The whole/partial ZK-tree is exported into a XML file. This helps in capturing a current snapshot of the data for backup/analysis. For a subtree export, one need to specify the path to the ZK-subtree with proper option. IMPORT: The ZK-tree can be imported from XML into ZK cluster. This helps in priming the new ZK cluster with static configuration. The import can be non-intrusive by making only the additions in the existing data. The import of subtree is also possible by optionally providing the path to the ZK-subtree. DIFF: Creates a diff between live ZK data vs data saved in XML file. Diff can ignore some ZK-tree branches (possibly dynamic data) on reading the optional ignore flag from XML file. Diffing on a ZK-subtree achieved by providing path to ZK-subtree with diff command. UPDATE: Make the incremental changes into the live ZK-tree from saved XML, essentia- lly after running the diff. DUMP: Dumps the ZK-tree on the standard output device reading either from live ZK server or XML file. Like export, ZK-subtree can be dumped with optionaly providing the path to the ZK-subtree, and till a certain depth of the (sub)tree. The exported ZK data into XML file can be shortened by only keeping the static ZK nodes which are required to prime a cluster. The dynamic zk nodes (created on-the- fly) can be ignored by setting a 'ignore' attribute at the root node of the dynamic subtree (see tests/zk_sample.xml), possibly deleting all inner ZK nodes under that. Once ignored, the whole subtree is ignored during DIFF, UPDATE and WRITE. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-496) zookeeper-tree utility for export, import and incremental updates
[ https://issues.apache.org/jira/browse/ZOOKEEPER-496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Reed updated ZOOKEEPER-496: Status: Patch Available (was: Open) zookeeper-tree utility for export, import and incremental updates - Key: ZOOKEEPER-496 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-496 Project: Zookeeper Issue Type: New Feature Components: contrib Environment: RHEL 4.6, libxml2 Reporter: Anirban Roy Assignee: Anirban Roy Fix For: 3.3.0 Attachments: zktreeutil.patch Original Estimate: 168h Remaining Estimate: 168h == zktreeutil - Zookeeper Tree Data Utility Author: Anirban Roy Organization: Yahoo Inc. == zktreeutil program is intended to manage and manipulate zk-tree data quickly, effi- ciently and with ease. The utility operates on free-form ZK-tree and hence can be used for any cluster managed by Zookeeper. Here are the basic functionalities - EXPORT: The whole/partial ZK-tree is exported into a XML file. This helps in capturing a current snapshot of the data for backup/analysis. For a subtree export, one need to specify the path to the ZK-subtree with proper option. IMPORT: The ZK-tree can be imported from XML into ZK cluster. This helps in priming the new ZK cluster with static configuration. The import can be non-intrusive by making only the additions in the existing data. The import of subtree is also possible by optionally providing the path to the ZK-subtree. DIFF: Creates a diff between live ZK data vs data saved in XML file. Diff can ignore some ZK-tree branches (possibly dynamic data) on reading the optional ignore flag from XML file. Diffing on a ZK-subtree achieved by providing path to ZK-subtree with diff command. UPDATE: Make the incremental changes into the live ZK-tree from saved XML, essentia- lly after running the diff. DUMP: Dumps the ZK-tree on the standard output device reading either from live ZK server or XML file. Like export, ZK-subtree can be dumped with optionaly providing the path to the ZK-subtree, and till a certain depth of the (sub)tree. The exported ZK data into XML file can be shortened by only keeping the static ZK nodes which are required to prime a cluster. The dynamic zk nodes (created on-the- fly) can be ignored by setting a 'ignore' attribute at the root node of the dynamic subtree (see tests/zk_sample.xml), possibly deleting all inner ZK nodes under that. Once ignored, the whole subtree is ignored during DIFF, UPDATE and WRITE. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-496) zookeeper-tree utility for export, import and incremental updates
[ https://issues.apache.org/jira/browse/ZOOKEEPER-496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Reed updated ZOOKEEPER-496: Status: Open (was: Patch Available) this looks pretty cool anirban, unfortunately i cannot get it to compile: in one of the .h files you have a qualified member, which should not be qualified; you need to include string.h when you use memset; and the resulting makefile does not include zookeeper.so as a required library. the readme should also list libboost as a required library. this is minor, but could you also change the tabs to 4 spaces? i also notice that you use strings for values. what will happen in the values are binary? zookeeper-tree utility for export, import and incremental updates - Key: ZOOKEEPER-496 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-496 Project: Zookeeper Issue Type: New Feature Components: contrib Environment: RHEL 4.6, libxml2 Reporter: Anirban Roy Assignee: Anirban Roy Fix For: 3.3.0 Attachments: zktreeutil.patch Original Estimate: 168h Remaining Estimate: 168h == zktreeutil - Zookeeper Tree Data Utility Author: Anirban Roy Organization: Yahoo Inc. == zktreeutil program is intended to manage and manipulate zk-tree data quickly, effi- ciently and with ease. The utility operates on free-form ZK-tree and hence can be used for any cluster managed by Zookeeper. Here are the basic functionalities - EXPORT: The whole/partial ZK-tree is exported into a XML file. This helps in capturing a current snapshot of the data for backup/analysis. For a subtree export, one need to specify the path to the ZK-subtree with proper option. IMPORT: The ZK-tree can be imported from XML into ZK cluster. This helps in priming the new ZK cluster with static configuration. The import can be non-intrusive by making only the additions in the existing data. The import of subtree is also possible by optionally providing the path to the ZK-subtree. DIFF: Creates a diff between live ZK data vs data saved in XML file. Diff can ignore some ZK-tree branches (possibly dynamic data) on reading the optional ignore flag from XML file. Diffing on a ZK-subtree achieved by providing path to ZK-subtree with diff command. UPDATE: Make the incremental changes into the live ZK-tree from saved XML, essentia- lly after running the diff. DUMP: Dumps the ZK-tree on the standard output device reading either from live ZK server or XML file. Like export, ZK-subtree can be dumped with optionaly providing the path to the ZK-subtree, and till a certain depth of the (sub)tree. The exported ZK data into XML file can be shortened by only keeping the static ZK nodes which are required to prime a cluster. The dynamic zk nodes (created on-the- fly) can be ignored by setting a 'ignore' attribute at the root node of the dynamic subtree (see tests/zk_sample.xml), possibly deleting all inner ZK nodes under that. Once ignored, the whole subtree is ignored during DIFF, UPDATE and WRITE. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (ZOOKEEPER-639) Performance improvements for ZooKeeper
Performance improvements for ZooKeeper -- Key: ZOOKEEPER-639 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-639 Project: Zookeeper Issue Type: Improvement Components: server Reporter: Benjamin Reed here are some more improvements to Zab. the patch is a bit stale, but i don't want to lose track of it. there are two big improvements: 1) transaction logs are reused. this saves time over growing the log files and if you preallocate a bunch of log files on an empty partition, you will see a nice performance boost 2) acks and commits are always sent in order, so if there is a bunch to send, they will get merged into a single ack or commit. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-639) Performance improvements for ZooKeeper
[ https://issues.apache.org/jira/browse/ZOOKEEPER-639?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Reed updated ZOOKEEPER-639: Attachment: ZOOKEEPER-639.patch Performance improvements for ZooKeeper -- Key: ZOOKEEPER-639 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-639 Project: Zookeeper Issue Type: Improvement Components: server Reporter: Benjamin Reed Attachments: ZOOKEEPER-639.patch here are some more improvements to Zab. the patch is a bit stale, but i don't want to lose track of it. there are two big improvements: 1) transaction logs are reused. this saves time over growing the log files and if you preallocate a bunch of log files on an empty partition, you will see a nice performance boost 2) acks and commits are always sent in order, so if there is a bunch to send, they will get merged into a single ack or commit. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-638) upgrade ivy to 2.1.0 final from 2.1.0 release candidate
[ https://issues.apache.org/jira/browse/ZOOKEEPER-638?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Reed updated ZOOKEEPER-638: Status: Patch Available (was: Open) upgrade ivy to 2.1.0 final from 2.1.0 release candidate --- Key: ZOOKEEPER-638 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-638 Project: Zookeeper Issue Type: Improvement Components: build Reporter: Patrick Hunt Assignee: Patrick Hunt Fix For: 3.3.0 Attachments: ZOOKEEPER-638.patch 2.1.0 is now available -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-496) zookeeper-tree utility for export, import and incremental updates
[ https://issues.apache.org/jira/browse/ZOOKEEPER-496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12799291#action_12799291 ] Benjamin Reed commented on ZOOKEEPER-496: - looks good anirban. sorry to be such a pain about this, but you still have tabs in the code. you need to be using spaces instead of tabs. zookeeper-tree utility for export, import and incremental updates - Key: ZOOKEEPER-496 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-496 Project: Zookeeper Issue Type: New Feature Components: contrib Environment: RHEL 4.6, libxml2 Reporter: Anirban Roy Assignee: Anirban Roy Fix For: 3.3.0 Attachments: zktreeutil.patch Original Estimate: 168h Remaining Estimate: 168h == zktreeutil - Zookeeper Tree Data Utility Author: Anirban Roy Organization: Yahoo Inc. == zktreeutil program is intended to manage and manipulate zk-tree data quickly, effi- ciently and with ease. The utility operates on free-form ZK-tree and hence can be used for any cluster managed by Zookeeper. Here are the basic functionalities - EXPORT: The whole/partial ZK-tree is exported into a XML file. This helps in capturing a current snapshot of the data for backup/analysis. For a subtree export, one need to specify the path to the ZK-subtree with proper option. IMPORT: The ZK-tree can be imported from XML into ZK cluster. This helps in priming the new ZK cluster with static configuration. The import can be non-intrusive by making only the additions in the existing data. The import of subtree is also possible by optionally providing the path to the ZK-subtree. DIFF: Creates a diff between live ZK data vs data saved in XML file. Diff can ignore some ZK-tree branches (possibly dynamic data) on reading the optional ignore flag from XML file. Diffing on a ZK-subtree achieved by providing path to ZK-subtree with diff command. UPDATE: Make the incremental changes into the live ZK-tree from saved XML, essentia- lly after running the diff. DUMP: Dumps the ZK-tree on the standard output device reading either from live ZK server or XML file. Like export, ZK-subtree can be dumped with optionaly providing the path to the ZK-subtree, and till a certain depth of the (sub)tree. The exported ZK data into XML file can be shortened by only keeping the static ZK nodes which are required to prime a cluster. The dynamic zk nodes (created on-the- fly) can be ignored by setting a 'ignore' attribute at the root node of the dynamic subtree (see tests/zk_sample.xml), possibly deleting all inner ZK nodes under that. Once ignored, the whole subtree is ignored during DIFF, UPDATE and WRITE. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-496) zookeeper-tree utility for export, import and incremental updates
[ https://issues.apache.org/jira/browse/ZOOKEEPER-496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Reed updated ZOOKEEPER-496: Status: Open (was: Patch Available) zookeeper-tree utility for export, import and incremental updates - Key: ZOOKEEPER-496 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-496 Project: Zookeeper Issue Type: New Feature Components: contrib Environment: RHEL 4.6, libxml2 Reporter: Anirban Roy Assignee: Anirban Roy Fix For: 3.3.0 Attachments: zktreeutil.patch, zktreeutil_2.patch Original Estimate: 168h Remaining Estimate: 168h == zktreeutil - Zookeeper Tree Data Utility Author: Anirban Roy Organization: Yahoo Inc. == zktreeutil program is intended to manage and manipulate zk-tree data quickly, effi- ciently and with ease. The utility operates on free-form ZK-tree and hence can be used for any cluster managed by Zookeeper. Here are the basic functionalities - EXPORT: The whole/partial ZK-tree is exported into a XML file. This helps in capturing a current snapshot of the data for backup/analysis. For a subtree export, one need to specify the path to the ZK-subtree with proper option. IMPORT: The ZK-tree can be imported from XML into ZK cluster. This helps in priming the new ZK cluster with static configuration. The import can be non-intrusive by making only the additions in the existing data. The import of subtree is also possible by optionally providing the path to the ZK-subtree. DIFF: Creates a diff between live ZK data vs data saved in XML file. Diff can ignore some ZK-tree branches (possibly dynamic data) on reading the optional ignore flag from XML file. Diffing on a ZK-subtree achieved by providing path to ZK-subtree with diff command. UPDATE: Make the incremental changes into the live ZK-tree from saved XML, essentia- lly after running the diff. DUMP: Dumps the ZK-tree on the standard output device reading either from live ZK server or XML file. Like export, ZK-subtree can be dumped with optionaly providing the path to the ZK-subtree, and till a certain depth of the (sub)tree. The exported ZK data into XML file can be shortened by only keeping the static ZK nodes which are required to prime a cluster. The dynamic zk nodes (created on-the- fly) can be ignored by setting a 'ignore' attribute at the root node of the dynamic subtree (see tests/zk_sample.xml), possibly deleting all inner ZK nodes under that. Once ignored, the whole subtree is ignored during DIFF, UPDATE and WRITE. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-496) zookeeper-tree utility for export, import and incremental updates
[ https://issues.apache.org/jira/browse/ZOOKEEPER-496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Reed updated ZOOKEEPER-496: Hadoop Flags: [Reviewed] zookeeper-tree utility for export, import and incremental updates - Key: ZOOKEEPER-496 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-496 Project: Zookeeper Issue Type: New Feature Components: contrib Environment: RHEL 4.6, libxml2 Reporter: Anirban Roy Assignee: Anirban Roy Fix For: 3.3.0 Attachments: zktreeutil.patch, zktreeutil_2.patch Original Estimate: 168h Remaining Estimate: 168h == zktreeutil - Zookeeper Tree Data Utility Author: Anirban Roy Organization: Yahoo Inc. == zktreeutil program is intended to manage and manipulate zk-tree data quickly, effi- ciently and with ease. The utility operates on free-form ZK-tree and hence can be used for any cluster managed by Zookeeper. Here are the basic functionalities - EXPORT: The whole/partial ZK-tree is exported into a XML file. This helps in capturing a current snapshot of the data for backup/analysis. For a subtree export, one need to specify the path to the ZK-subtree with proper option. IMPORT: The ZK-tree can be imported from XML into ZK cluster. This helps in priming the new ZK cluster with static configuration. The import can be non-intrusive by making only the additions in the existing data. The import of subtree is also possible by optionally providing the path to the ZK-subtree. DIFF: Creates a diff between live ZK data vs data saved in XML file. Diff can ignore some ZK-tree branches (possibly dynamic data) on reading the optional ignore flag from XML file. Diffing on a ZK-subtree achieved by providing path to ZK-subtree with diff command. UPDATE: Make the incremental changes into the live ZK-tree from saved XML, essentia- lly after running the diff. DUMP: Dumps the ZK-tree on the standard output device reading either from live ZK server or XML file. Like export, ZK-subtree can be dumped with optionaly providing the path to the ZK-subtree, and till a certain depth of the (sub)tree. The exported ZK data into XML file can be shortened by only keeping the static ZK nodes which are required to prime a cluster. The dynamic zk nodes (created on-the- fly) can be ignored by setting a 'ignore' attribute at the root node of the dynamic subtree (see tests/zk_sample.xml), possibly deleting all inner ZK nodes under that. Once ignored, the whole subtree is ignored during DIFF, UPDATE and WRITE. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-496) zookeeper-tree utility for export, import and incremental updates
[ https://issues.apache.org/jira/browse/ZOOKEEPER-496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Reed updated ZOOKEEPER-496: Status: Patch Available (was: Open) zookeeper-tree utility for export, import and incremental updates - Key: ZOOKEEPER-496 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-496 Project: Zookeeper Issue Type: New Feature Components: contrib Environment: RHEL 4.6, libxml2 Reporter: Anirban Roy Assignee: Anirban Roy Fix For: 3.3.0 Attachments: zktreeutil.patch, zktreeutil_2.patch Original Estimate: 168h Remaining Estimate: 168h == zktreeutil - Zookeeper Tree Data Utility Author: Anirban Roy Organization: Yahoo Inc. == zktreeutil program is intended to manage and manipulate zk-tree data quickly, effi- ciently and with ease. The utility operates on free-form ZK-tree and hence can be used for any cluster managed by Zookeeper. Here are the basic functionalities - EXPORT: The whole/partial ZK-tree is exported into a XML file. This helps in capturing a current snapshot of the data for backup/analysis. For a subtree export, one need to specify the path to the ZK-subtree with proper option. IMPORT: The ZK-tree can be imported from XML into ZK cluster. This helps in priming the new ZK cluster with static configuration. The import can be non-intrusive by making only the additions in the existing data. The import of subtree is also possible by optionally providing the path to the ZK-subtree. DIFF: Creates a diff between live ZK data vs data saved in XML file. Diff can ignore some ZK-tree branches (possibly dynamic data) on reading the optional ignore flag from XML file. Diffing on a ZK-subtree achieved by providing path to ZK-subtree with diff command. UPDATE: Make the incremental changes into the live ZK-tree from saved XML, essentia- lly after running the diff. DUMP: Dumps the ZK-tree on the standard output device reading either from live ZK server or XML file. Like export, ZK-subtree can be dumped with optionaly providing the path to the ZK-subtree, and till a certain depth of the (sub)tree. The exported ZK data into XML file can be shortened by only keeping the static ZK nodes which are required to prime a cluster. The dynamic zk nodes (created on-the- fly) can be ignored by setting a 'ignore' attribute at the root node of the dynamic subtree (see tests/zk_sample.xml), possibly deleting all inner ZK nodes under that. Once ignored, the whole subtree is ignored during DIFF, UPDATE and WRITE. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-496) zookeeper-tree utility for export, import and incremental updates
[ https://issues.apache.org/jira/browse/ZOOKEEPER-496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Reed updated ZOOKEEPER-496: Resolution: Fixed Status: Resolved (was: Patch Available) Committed revision 898542. thanx anirban! zookeeper-tree utility for export, import and incremental updates - Key: ZOOKEEPER-496 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-496 Project: Zookeeper Issue Type: New Feature Components: contrib Environment: RHEL 4.6, libxml2 Reporter: Anirban Roy Assignee: Anirban Roy Fix For: 3.3.0 Attachments: zktreeutil.patch, zktreeutil_2.patch Original Estimate: 168h Remaining Estimate: 168h == zktreeutil - Zookeeper Tree Data Utility Author: Anirban Roy Organization: Yahoo Inc. == zktreeutil program is intended to manage and manipulate zk-tree data quickly, effi- ciently and with ease. The utility operates on free-form ZK-tree and hence can be used for any cluster managed by Zookeeper. Here are the basic functionalities - EXPORT: The whole/partial ZK-tree is exported into a XML file. This helps in capturing a current snapshot of the data for backup/analysis. For a subtree export, one need to specify the path to the ZK-subtree with proper option. IMPORT: The ZK-tree can be imported from XML into ZK cluster. This helps in priming the new ZK cluster with static configuration. The import can be non-intrusive by making only the additions in the existing data. The import of subtree is also possible by optionally providing the path to the ZK-subtree. DIFF: Creates a diff between live ZK data vs data saved in XML file. Diff can ignore some ZK-tree branches (possibly dynamic data) on reading the optional ignore flag from XML file. Diffing on a ZK-subtree achieved by providing path to ZK-subtree with diff command. UPDATE: Make the incremental changes into the live ZK-tree from saved XML, essentia- lly after running the diff. DUMP: Dumps the ZK-tree on the standard output device reading either from live ZK server or XML file. Like export, ZK-subtree can be dumped with optionaly providing the path to the ZK-subtree, and till a certain depth of the (sub)tree. The exported ZK data into XML file can be shortened by only keeping the static ZK nodes which are required to prime a cluster. The dynamic zk nodes (created on-the- fly) can be ignored by setting a 'ignore' attribute at the root node of the dynamic subtree (see tests/zk_sample.xml), possibly deleting all inner ZK nodes under that. Once ignored, the whole subtree is ignored during DIFF, UPDATE and WRITE. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-638) upgrade ivy to 2.1.0 final from 2.1.0 release candidate
[ https://issues.apache.org/jira/browse/ZOOKEEPER-638?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Reed updated ZOOKEEPER-638: Resolution: Fixed Status: Resolved (was: Patch Available) Committed revision 898544. thanx pat! upgrade ivy to 2.1.0 final from 2.1.0 release candidate --- Key: ZOOKEEPER-638 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-638 Project: Zookeeper Issue Type: Improvement Components: build Reporter: Patrick Hunt Assignee: Patrick Hunt Fix For: 3.3.0 Attachments: ZOOKEEPER-638.patch 2.1.0 is now available -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-507) BookKeeper client re-write
[ https://issues.apache.org/jira/browse/ZOOKEEPER-507?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Reed updated ZOOKEEPER-507: Attachment: ZOOKEEPER-507.patch two extremely small fixes to make the tests patch: 1) The syncThread was not being killed in the shutdown() method of Bookie 2) We need to add pending ops before calling connect() in PerChannelBookieConnection because in linux with local host the connect will return immediately. we really need to commit this thing. the patch has become extremely unwieldy! BookKeeper client re-write -- Key: ZOOKEEPER-507 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-507 Project: Zookeeper Issue Type: Improvement Components: contrib-bookkeeper Reporter: Flavio Paiva Junqueira Assignee: Utkarsh Srivastava Fix For: 3.3.0 Attachments: BookieFailureTest-log-507.rtf, ZOOKEEPER-507.patch, ZOOKEEPER-507.patch, ZOOKEEPER-507.patch, ZOOKEEPER-507.patch, ZOOKEEPER-507.patch Error handling is far from ideal currently in the BookKeeper client. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (ZOOKEEPER-659) improve bookkeeper javadocs for internal classes
improve bookkeeper javadocs for internal classes Key: ZOOKEEPER-659 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-659 Project: Zookeeper Issue Type: Bug Affects Versions: 3.3.0 Reporter: Benjamin Reed Fix For: 3.3.0 the internal classes of bookkeeper are lacking javadoc. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-622) Test for pending watches in send_set_watches should be moved
[
https://issues.apache.org/jira/browse/ZOOKEEPER-622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12805515#action_12805515
]
Benjamin Reed commented on ZOOKEEPER-622:
-
good catch steven and excellent patch! will you put the license header in the
generateCfgs.sh script? will you also put the header at the end of
localserverlist (making it a footer :) to avoid a release warning?
Test for pending watches in send_set_watches should be moved
Key: ZOOKEEPER-622
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-622
Project: Zookeeper
Issue Type: Bug
Components: c client
Reporter: Steven Cheng
Assignee: Benjamin Reed
Fix For: 3.3.0
Attachments: ZOOKEEPER-622.patch, ZOOKEEPER-622.patch
Valgrind found:
{quote}
==2357== Conditional jump or move depends on uninitialised value(s)
==2357==at 0x807FDCA: check_events (zookeeper.c:1180)
==2357==by 0x808043A: zookeeper_process (zookeeper.c:1775)
==2357==by 0x806A21B: Zookeeper_close::testCloseConnected1()
(TestZookeeperClose.cc:161)
==2357==by 0x806C6BF: CppUnit::TestCallerZookeeper_close::runTest()
(TestCaller.h:166)
{quote}
zookeeper.c:1180 was the first if in send_set_watches.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-622) Test for pending watches in send_set_watches should be moved
[
https://issues.apache.org/jira/browse/ZOOKEEPER-622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12805524#action_12805524
]
Benjamin Reed commented on ZOOKEEPER-622:
-
sorry, i looked at this a bit more closely and i realized that we can't really
assume that there is a /tmp. we should be using ${base_dir}/build/tmp/ i'll
take a whack at fixing the zkMultiServer.sh.
Test for pending watches in send_set_watches should be moved
Key: ZOOKEEPER-622
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-622
Project: Zookeeper
Issue Type: Bug
Components: c client
Reporter: Steven Cheng
Assignee: Benjamin Reed
Fix For: 3.3.0
Attachments: ZOOKEEPER-622.patch, ZOOKEEPER-622.patch
Valgrind found:
{quote}
==2357== Conditional jump or move depends on uninitialised value(s)
==2357==at 0x807FDCA: check_events (zookeeper.c:1180)
==2357==by 0x808043A: zookeeper_process (zookeeper.c:1775)
==2357==by 0x806A21B: Zookeeper_close::testCloseConnected1()
(TestZookeeperClose.cc:161)
==2357==by 0x806C6BF: CppUnit::TestCallerZookeeper_close::runTest()
(TestCaller.h:166)
{quote}
zookeeper.c:1180 was the first if in send_set_watches.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-622) Test for pending watches in send_set_watches should be moved
[
https://issues.apache.org/jira/browse/ZOOKEEPER-622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12805631#action_12805631
]
Benjamin Reed commented on ZOOKEEPER-622:
-
hey steven, it appears the test case isn't testing anything. can you clarify
how it works?
Test for pending watches in send_set_watches should be moved
Key: ZOOKEEPER-622
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-622
Project: Zookeeper
Issue Type: Bug
Components: c client
Reporter: Steven Cheng
Assignee: Benjamin Reed
Fix For: 3.3.0
Attachments: ZOOKEEPER-622.patch, ZOOKEEPER-622.patch
Valgrind found:
{quote}
==2357== Conditional jump or move depends on uninitialised value(s)
==2357==at 0x807FDCA: check_events (zookeeper.c:1180)
==2357==by 0x808043A: zookeeper_process (zookeeper.c:1775)
==2357==by 0x806A21B: Zookeeper_close::testCloseConnected1()
(TestZookeeperClose.cc:161)
==2357==by 0x806C6BF: CppUnit::TestCallerZookeeper_close::runTest()
(TestCaller.h:166)
{quote}
zookeeper.c:1180 was the first if in send_set_watches.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-622) Test for pending watches in send_set_watches should be moved
[
https://issues.apache.org/jira/browse/ZOOKEEPER-622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Reed updated ZOOKEEPER-622:
Status: Open (was: Patch Available)
Test for pending watches in send_set_watches should be moved
Key: ZOOKEEPER-622
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-622
Project: Zookeeper
Issue Type: Bug
Components: c client
Reporter: Steven Cheng
Assignee: Benjamin Reed
Fix For: 3.3.0
Attachments: ZOOKEEPER-622.patch, ZOOKEEPER-622.patch
Valgrind found:
{quote}
==2357== Conditional jump or move depends on uninitialised value(s)
==2357==at 0x807FDCA: check_events (zookeeper.c:1180)
==2357==by 0x808043A: zookeeper_process (zookeeper.c:1775)
==2357==by 0x806A21B: Zookeeper_close::testCloseConnected1()
(TestZookeeperClose.cc:161)
==2357==by 0x806C6BF: CppUnit::TestCallerZookeeper_close::runTest()
(TestCaller.h:166)
{quote}
zookeeper.c:1180 was the first if in send_set_watches.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-524) DBSizeTest is not really testing anything
[ https://issues.apache.org/jira/browse/ZOOKEEPER-524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12805991#action_12805991 ] Benjamin Reed commented on ZOOKEEPER-524: - is there any objection to removing the test. (especially since it isn't doing anything?) DBSizeTest is not really testing anything - Key: ZOOKEEPER-524 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-524 Project: Zookeeper Issue Type: Bug Components: server, tests Reporter: Patrick Hunt Assignee: Benjamin Reed Priority: Minor Fix For: 3.3.0 DBSizeTest looks like it should be testing latency, but it doesn't seem to do it (assert is commented out). We need to decide if this test should be fixed, or just dropped. Also note: this test takes 40seconds on my system. Way too long. Perhaps async create operations should be used to populate the database. I also noticed that data size has a big impact on overall test time (1k vs 5 bytes is something like a 2x time diff for time to run the test). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-589) When create a znode, a NULL ACL parameter cannot be accepted
[ https://issues.apache.org/jira/browse/ZOOKEEPER-589?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12828238#action_12828238 ] Benjamin Reed commented on ZOOKEEPER-589: - i think we should fix the client docs to reflect this behavior. ACL of the parent is a bit ambiguous if the parent's ACL changes after the create. it also will be problematic when we do federated ZooKeeper. When create a znode, a NULL ACL parameter cannot be accepted Key: ZOOKEEPER-589 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-589 Project: Zookeeper Issue Type: Bug Components: c client Affects Versions: 3.2.1 Environment: Linux db-passport-test05.vm 2.6.9_5-4-0-5 #1 SMP Tue Apr 14 15:56:24 CST 2009 x86_64 x86_64 x86_64 GNU/Linux Reporter: Qian Ye Fix For: 3.3.0 In the comments of client C API which associated with creating znode, eg. zoo_acreate, it is said that the initial ACL of the node if null, the ACL of the parent will be used. However, the it doesn't work. When execute this kind of request at the server side, it raises InvalidACLException. The source code show that, the function fixupACL return false when it get a null ACL. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
