[jira] Commented: (ZOOKEEPER-245) update readme/quickstart to be release tar, rather than source, based
[ https://issues.apache.org/jira/browse/ZOOKEEPER-245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12655028#action_12655028 ] Mahadev konar commented on ZOOKEEPER-245: - +1 for the patch... update readme/quickstart to be release tar, rather than source, based - Key: ZOOKEEPER-245 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-245 Project: Zookeeper Issue Type: Bug Components: documentation Affects Versions: 3.0.1 Reporter: Patrick Hunt Assignee: Patrick Hunt Fix For: 3.1.0 Attachments: ZOOKEEPER-245.patch Owen O'Malley mentioned: - we need to change both the README and quick start to assume you are working with a release instead of a source tarball. Apache releases are the approved way of getting the project. Documentation that assumes they are getting source themselves doesn't reflect that. - -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-250) isvalidsnapshot should handle the case of 0 snapshot files better.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mahadev konar updated ZOOKEEPER-250: Attachment: ZOOKEEPER-250.patch this patch recreates the test case with corrupting the last snapshot adn then brings back the server and checks the validity of data. the test fails without the patch. isvalidsnapshot should handle the case of 0 snapshot files better. -- Key: ZOOKEEPER-250 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-250 Project: Zookeeper Issue Type: Bug Affects Versions: 3.0.0, 3.0.1 Reporter: Mahadev konar Assignee: Mahadev konar Fix For: 3.1.0 Attachments: ZOOKEEPER-250.patch, ZOOKEEPER-250.patch the isvalidsnapshot will fail with negative seek if 0 snapshot files exist. We should just return false in case the size of the snapshot is less than 5 bytes. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-250) isvalidsnapshot should handle the case of 0 snapshot files better.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mahadev konar updated ZOOKEEPER-250: Status: Patch Available (was: Open) isvalidsnapshot should handle the case of 0 snapshot files better. -- Key: ZOOKEEPER-250 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-250 Project: Zookeeper Issue Type: Bug Affects Versions: 3.0.1, 3.0.0 Reporter: Mahadev konar Assignee: Mahadev konar Fix For: 3.1.0 Attachments: ZOOKEEPER-250.patch, ZOOKEEPER-250.patch the isvalidsnapshot will fail with negative seek if 0 snapshot files exist. We should just return false in case the size of the snapshot is less than 5 bytes. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-246) review error code definition in both source and docs
[ https://issues.apache.org/jira/browse/ZOOKEEPER-246?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mahadev konar updated ZOOKEEPER-246: Status: Open (was: Patch Available) cancelling the patch to address the comments., review error code definition in both source and docs Key: ZOOKEEPER-246 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-246 Project: Zookeeper Issue Type: Improvement Components: c client, documentation, java client Affects Versions: 3.0.1, 3.0.0 Reporter: Patrick Hunt Assignee: Patrick Hunt Priority: Minor Fix For: 3.1.0 Attachments: ZOOKEEPER-246.patch A number of users have mentioned that our use of calculated values for error codes makes it very difficult to track error reports from the logs. In both c/java we have: int ERROR = 100 int X_ERROR= ERROR + 1 int Y_ERROR= ERROR + 2 etc... which makes it difficult to grep/search for 101 and find these references. A number of users have mentioned that having non-calculated values (ie X_ERROR=101) would make it easier. I personally find calculated constants like this an anti-pattern. We should convert these values to non-calculated at a minimum, perhaps even redefine them as enums if possible. Also documentation, esp in the c code (the names btw c and java don't match btw) is lacking. We need to beef up docs in this area. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-246) review error code definition in both source and docs
[ https://issues.apache.org/jira/browse/ZOOKEEPER-246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12656137#action_12656137 ] Mahadev konar commented on ZOOKEEPER-246: - comments: - the static create method KeeperException.create(int) has been removed. We need to keep it for b/w compatibility. - also a little bit more doucmentation on APIERROR would help (both c and java) . you can say that all the api errors start from here, all the others are less than this (more explict than just range start). also, mention that this error is not thrown by the server but is just the range start. review error code definition in both source and docs Key: ZOOKEEPER-246 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-246 Project: Zookeeper Issue Type: Improvement Components: c client, documentation, java client Affects Versions: 3.0.0, 3.0.1 Reporter: Patrick Hunt Assignee: Patrick Hunt Priority: Minor Fix For: 3.1.0 Attachments: ZOOKEEPER-246.patch A number of users have mentioned that our use of calculated values for error codes makes it very difficult to track error reports from the logs. In both c/java we have: int ERROR = 100 int X_ERROR= ERROR + 1 int Y_ERROR= ERROR + 2 etc... which makes it difficult to grep/search for 101 and find these references. A number of users have mentioned that having non-calculated values (ie X_ERROR=101) would make it easier. I personally find calculated constants like this an anti-pattern. We should convert these values to non-calculated at a minimum, perhaps even redefine them as enums if possible. Also documentation, esp in the c code (the names btw c and java don't match btw) is lacking. We need to beef up docs in this area. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-230) Improvements to FLE
[ https://issues.apache.org/jira/browse/ZOOKEEPER-230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mahadev konar updated ZOOKEEPER-230: Attachment: ZOOKEEPER-230.patch ok fixed the comments i had, and also removed some unused variables in the code. Improvements to FLE --- Key: ZOOKEEPER-230 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-230 Project: Zookeeper Issue Type: Improvement Components: leaderElection Affects Versions: 3.0.0 Reporter: Flavio Paiva Junqueira Assignee: Flavio Paiva Junqueira Fix For: 3.1.0 Attachments: ZOOKEEPER-230.patch, ZOOKEEPER-230.patch, ZOOKEEPER-230.patch, ZOOKEEPER-230.patch, ZOOKEEPER-230.patch I'm about to attach a patch that implements the following modifications: . Currently, if a server is on leader election and doesn't receive a notification for some amount of time t, then it sends a new set of notifications if at least one server has delivered a message from the previous set. With this patch, the amount of time a server waits for a notification before sending a new set increases exponentially; . I have separated connecting to servers and queuing new notification messages. Before they were all in the same message. The advantage is that now I can tell to an instance of QuorumCnxManager to try to connect to other servers without generating new notification messages; . I have changed the logging level of several messages on QuorumCnxManager. They were warn, but they should really be either info or debug. I've changed them to info. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-225) c client should log an info message in zookeeper_init detailing connection parameters
[ https://issues.apache.org/jira/browse/ZOOKEEPER-225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mahadev konar updated ZOOKEEPER-225: Attachment: ZOOKEEPER-225.patch just reformatted a log line to break it up into 2 lines. c client should log an info message in zookeeper_init detailing connection parameters - Key: ZOOKEEPER-225 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-225 Project: Zookeeper Issue Type: Improvement Components: c client Affects Versions: 3.0.0, 3.0.1 Reporter: Patrick Hunt Assignee: Patrick Hunt Priority: Minor Fix For: 3.1.0 Attachments: ZOOKEEPER-225.patch, ZOOKEEPER-225.patch I've debugged a few situations where the client connection param was not set properly (even though the user swore that it was). We should log info level message during init to enable us (and user) to easier debug. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-225) c client should log an info message in zookeeper_init detailing connection parameters
[ https://issues.apache.org/jira/browse/ZOOKEEPER-225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mahadev konar updated ZOOKEEPER-225: Resolution: Fixed Hadoop Flags: [Reviewed] Status: Resolved (was: Patch Available) i just committed this. thanks pat. c client should log an info message in zookeeper_init detailing connection parameters - Key: ZOOKEEPER-225 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-225 Project: Zookeeper Issue Type: Improvement Components: c client Affects Versions: 3.0.0, 3.0.1 Reporter: Patrick Hunt Assignee: Patrick Hunt Priority: Minor Fix For: 3.1.0 Attachments: ZOOKEEPER-225.patch, ZOOKEEPER-225.patch I've debugged a few situations where the client connection param was not set properly (even though the user swore that it was). We should log info level message during init to enable us (and user) to easier debug. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (ZOOKEEPER-255) zoo_set() api does not return stat datastructure.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mahadev konar reassigned ZOOKEEPER-255: --- Assignee: Avery Ching assigning it to avery. zoo_set() api does not return stat datastructure. - Key: ZOOKEEPER-255 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-255 Project: Zookeeper Issue Type: Bug Affects Versions: 3.0.0, 3.0.1 Reporter: Mahadev konar Assignee: Avery Ching Priority: Blocker Fix For: 3.1.0 Attachments: diff.txt the zoo_set() api does not return the stat datastructure. the java counterpart returns a stat with set api. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-255) zoo_set() api does not return stat datastructure.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mahadev konar updated ZOOKEEPER-255: Component/s: c client zoo_set() api does not return stat datastructure. - Key: ZOOKEEPER-255 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-255 Project: Zookeeper Issue Type: Bug Components: c client Affects Versions: 3.0.0, 3.0.1 Reporter: Mahadev konar Assignee: Avery Ching Priority: Blocker Fix For: 3.1.0 Attachments: diff.txt the zoo_set() api does not return the stat datastructure. the java counterpart returns a stat with set api. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-222) print C client log message timestamp in human readable form
[ https://issues.apache.org/jira/browse/ZOOKEEPER-222?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mahadev konar updated ZOOKEEPER-222: Resolution: Fixed Hadoop Flags: [Reviewed] Status: Resolved (was: Patch Available) I just committed this. thanks pat. print C client log message timestamp in human readable form --- Key: ZOOKEEPER-222 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-222 Project: Zookeeper Issue Type: Improvement Components: c client Affects Versions: 3.0.0 Reporter: Patrick Hunt Assignee: Patrick Hunt Priority: Minor Fix For: 3.1.0 Attachments: ZOOKEEPER-222.patch Noticed this issue during a debugging session -- it's difficult to read/compare the timestamps from the c client. The C client timestamp should be formatted with the same format as the JAVA log timestamps. Note: java uses ISO8601 timestamp formatting by default. Perhaps we should just bit the bullet and move to log4c? Consider this option when addressing this issue. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (ZOOKEEPER-260) document the recommended values for server id's
document the recommended values for server id's --- Key: ZOOKEEPER-260 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-260 Project: Zookeeper Issue Type: Improvement Reporter: Mahadev konar Assignee: Mahadev konar currently we do nto doucment the recommended values for server id's. we should document that. For some large values of server id's we might get negative session's and also might get duplicate sessions from two servers. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-260) document the recommended values for server id's
[ https://issues.apache.org/jira/browse/ZOOKEEPER-260?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mahadev konar updated ZOOKEEPER-260: Affects Version/s: 3.0.0 3.0.1 Fix Version/s: 3.1.0 document the recommended values for server id's --- Key: ZOOKEEPER-260 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-260 Project: Zookeeper Issue Type: Improvement Affects Versions: 3.0.0, 3.0.1 Reporter: Mahadev konar Assignee: Mahadev konar Fix For: 3.1.0 currently we do nto doucment the recommended values for server id's. we should document that. For some large values of server id's we might get negative session's and also might get duplicate sessions from two servers. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-261) Reinitialized servers should not participate in leader election
[ https://issues.apache.org/jira/browse/ZOOKEEPER-261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12657936#action_12657936 ] Mahadev konar commented on ZOOKEEPER-261: - do we want to differentiate on losing all of data or some data (lets say someone deletes some of the log data or snapshots)? it might make sense not to, since losing some data is more like an accidental error and losing all of data is more like a disk failure : if not, what we could do is create a file --- lasttrackingxid and overwrite it every 1000 or 5000 transactions and on a startup if our last logged txn id is less than the lasttrackingxid then we could just not participate in the leader election saying that i lost some state. Reinitialized servers should not participate in leader election --- Key: ZOOKEEPER-261 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-261 Project: Zookeeper Issue Type: Improvement Components: leaderElection, quorum Reporter: Benjamin Reed A server that has lost its data should not participate in leader election until it has resynced with a leader. Our leader election algorithm and NEW_LEADER commit assumes that the followers voting on a leader have not lost any of their data. We should have a flag in the data directory saying whether or not the data is preserved so that the the flag will be cleared if the data is ever cleared. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-255) zoo_set() api does not return stat datastructure.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mahadev konar updated ZOOKEEPER-255: Resolution: Fixed Hadoop Flags: [Incompatible change, Reviewed] (was: [Incompatible change]) Status: Resolved (was: Patch Available) +1 on the patch. I just committed this. thanks avery! zoo_set() api does not return stat datastructure. - Key: ZOOKEEPER-255 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-255 Project: Zookeeper Issue Type: Bug Components: c client Affects Versions: 3.0.0, 3.0.1 Reporter: Mahadev konar Assignee: Avery Ching Priority: Blocker Fix For: 3.1.0 Attachments: ZOOKEEPER-255.patch, ZOOKEEPER-255.patch the zoo_set() api does not return the stat datastructure. the java counterpart returns a stat with set api. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-256) support use of JMX to manage log4j configuration at runtime
[ https://issues.apache.org/jira/browse/ZOOKEEPER-256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12658717#action_12658717 ] Mahadev konar commented on ZOOKEEPER-256: - ok... thats fine. +1 for the patch. Ill commit this then... support use of JMX to manage log4j configuration at runtime --- Key: ZOOKEEPER-256 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-256 Project: Zookeeper Issue Type: New Feature Components: jmx Reporter: Patrick Hunt Assignee: Patrick Hunt Fix For: 3.1.0 Attachments: ZOOKEEPER-256.patch Log4j has code to support management at runtime using JMX. Need to add hooks to register the beans. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-256) support use of JMX to manage log4j configuration at runtime
[ https://issues.apache.org/jira/browse/ZOOKEEPER-256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mahadev konar updated ZOOKEEPER-256: Resolution: Fixed Hadoop Flags: [Reviewed] Status: Resolved (was: Patch Available) I just committed this. Thanks pat! support use of JMX to manage log4j configuration at runtime --- Key: ZOOKEEPER-256 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-256 Project: Zookeeper Issue Type: New Feature Components: jmx Reporter: Patrick Hunt Assignee: Patrick Hunt Fix For: 3.1.0 Attachments: ZOOKEEPER-256.patch Log4j has code to support management at runtime using JMX. Need to add hooks to register the beans. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-214) add new stat reset command to server admin port
[ https://issues.apache.org/jira/browse/ZOOKEEPER-214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12658723#action_12658723 ] Mahadev konar commented on ZOOKEEPER-214: - +1 the patch looks good... just a nit... final static int enviCmd = ByteBuffer.wrap(envi.getBytes()).getInt(); +final static int srstCmd = ByteBuffer.wrap(srst.getBytes()).getInt(); + final static ByteBuffer imok = ByteBuffer.wrap(imok.getBytes()); itll be good to add javadoc for all these vars. Ill add some javadoc and then commit... add new stat reset command to server admin port - Key: ZOOKEEPER-214 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-214 Project: Zookeeper Issue Type: Improvement Components: server Reporter: Patrick Hunt Assignee: Patrick Hunt Fix For: 3.1.0 Attachments: ZOOKEEPER-214.patch A new command should be added to the server admin port (client port) that allows users to reset the stats. We saw cases during troubleshooting where we would have liked to reset the min/avg/max latency stats, but were unable to do so (short of restarting the server). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-214) add new stat reset command to server admin port
[ https://issues.apache.org/jira/browse/ZOOKEEPER-214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mahadev konar updated ZOOKEEPER-214: Attachment: ZOOKEEPER-214_1.patch this patch adds javadoc with a link to the forrest docs. add new stat reset command to server admin port - Key: ZOOKEEPER-214 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-214 Project: Zookeeper Issue Type: Improvement Components: server Reporter: Patrick Hunt Assignee: Patrick Hunt Fix For: 3.1.0 Attachments: ZOOKEEPER-214.patch, ZOOKEEPER-214_1.patch A new command should be added to the server admin port (client port) that allows users to reset the stats. We saw cases during troubleshooting where we would have liked to reset the min/avg/max latency stats, but were unable to do so (short of restarting the server). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-214) add new stat reset command to server admin port
[ https://issues.apache.org/jira/browse/ZOOKEEPER-214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mahadev konar updated ZOOKEEPER-214: Resolution: Fixed Hadoop Flags: [Reviewed] Status: Resolved (was: Patch Available) I just committed this. thanks pat. add new stat reset command to server admin port - Key: ZOOKEEPER-214 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-214 Project: Zookeeper Issue Type: Improvement Components: server Reporter: Patrick Hunt Assignee: Patrick Hunt Fix For: 3.1.0 Attachments: ZOOKEEPER-214.patch, ZOOKEEPER-214_1.patch A new command should be added to the server admin port (client port) that allows users to reset the stats. We saw cases during troubleshooting where we would have liked to reset the min/avg/max latency stats, but were unable to do so (short of restarting the server). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-262) unnecesssarily complex reentrant zookeeper_close() logic
[ https://issues.apache.org/jira/browse/ZOOKEEPER-262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12660436#action_12660436 ] Mahadev konar commented on ZOOKEEPER-262: - sorry for the late review chris i dont remember the reason why zookeeper_close() is the way it is right now. you patch certainly simplifies it ... and I dont see any reason for zookeeper_close() to be re entring itself (close calling itself via adaptor_finish) elt me think abt this more to see if I can come up with a reason for zookeeper_close() being the way it is now... unnecesssarily complex reentrant zookeeper_close() logic Key: ZOOKEEPER-262 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-262 Project: Zookeeper Issue Type: Improvement Components: c client Affects Versions: 3.0.0, 3.0.1, 3.1.0, 3.2.0, 4.0.0 Reporter: Chris Darroch Priority: Minor Fix For: 3.1.0, 3.2.0, 4.0.0 Attachments: zookeeper-close.patch While working on a wrapper for the C API I puzzled over the problem of how to determine when the multi-threaded adaptor's IO and completion threads had exited. Looking at the code in api_epilog() and adaptor_finish() it seemed clear that any thread could be the last one out the door, and whichever was last would turn out the lights by calling zookeeper_close(). However, on further examination I found that in fact, the close_requested flag guards entry to zookeeper_close() in api_epilog(), and close_requested can only be set non-zero within zookeeper_close(). Thus, only the user's main thread can invoke zookeeper_close() and kick off the shutdown process. When that happens, zookeeper_close() then invokes adaptor_finish() and returns ZOK immediately afterward. Since adaptor_finish() is only called in this one context, it means all the code in that function to check pthread_self() and call pthread_detach() if the current thread is the IO or completion thread is redundant. The adaptor_finish() function always signals and then waits to join with the IO and completion threads because it can only be called by the user's main thread. After joining with the two internal threads, adaptor_finish() calls api_epilog(), which might seem like a trivial final action. However, this is actually where all the work gets done, because in this one case, api_epilog() sees a non-zero close_requested flag value and invokes zookeeper_close(). Note that zookeeper_close() is already on the stack; this is a re-entrant invocation. This time around, zookeeper_close() skips the call to adaptor_finish() -- assuming the reference count has been properly decremented to zero! -- and does the actual final cleanup steps, including deallocating the zh structure. Fortunately, none of the callers on the stack (api_epilog(), adaptor_finish(), and the first zookeeper_close()) touches zh after this. This all works OK, and in particular, the fact that I can be certain that the IO and completion threads have exited after zookeeper_close() returns is great. So too is the fact that those threads can't invoke zookeeper_close() without my knowing about it. However, the actual mechanics of the shutdown seem unnecessarily complex. I'd be worried a bit about a new maintainer looking at adaptor_finish() and reasonably concluding that it can be called by any thread, including the IO and completion ones. Or thinking that the zh handle can still be used after that innocuous-looking call to adaptor_finish() in zookeeper_close() -- the one that actually causes all the work to be done and the handle to be deallocated! I'll attach a patch which I think simplifies the code a bit and makes the shutdown mechanics a little more clear, and might prevent unintentional errors in the future. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-231) Quotas in zookeeper
[ https://issues.apache.org/jira/browse/ZOOKEEPER-231?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mahadev konar updated ZOOKEEPER-231: Attachment: ZOOKEEPER-231.patch here is a preliminary patch for qutoa's. This is not fully complete -- lacking tests, documentation and a few minor features, which I will be adding shortly. The design is based on whats discussed above. COmments are welcome. Quotas in zookeeper --- Key: ZOOKEEPER-231 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-231 Project: Zookeeper Issue Type: New Feature Affects Versions: 3.0.0 Reporter: Mahadev konar Assignee: Mahadev konar Fix For: 3.1.0 Attachments: ZOOKEEPER-231.patch creating quota's in zookeeper so that a runaway application does not bring down the zookeeper cluster. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-268) tostring on jute generated objects can cause NPE
[
https://issues.apache.org/jira/browse/ZOOKEEPER-268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12662117#action_12662117
]
Mahadev konar commented on ZOOKEEPER-268:
-
the patch looks good except a nit..
{code}
/** Cannot create a new instance of Utils */
private Utils() {
+super();
}
{code}
why do we need to call super()? isnt it default object()?
tostring on jute generated objects can cause NPE
Key: ZOOKEEPER-268
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-268
Project: Zookeeper
Issue Type: Bug
Components: java client, server
Affects Versions: 3.0.0, 3.0.1
Reporter: Patrick Hunt
Assignee: Patrick Hunt
Fix For: 3.1.0
Attachments: ZOOKEEPER-268.patch
Jute still causing problems with tostring operations on generated code, need
to review/cleanup the toCSV code
From user Kevin Burton:
-
Creating this node with this ACL:
Created /foo
setAcl /foo world:anyone:w
Causes the exception included below.
It's an infinite loop so it's just called over and over again filling my
console.
I'm just doing an exists( path, true ); ... setting a watch still causes the
problem.
java.lang.NullPointerException
at org.apache.jute.Utils.toCSVBuffer(Utils.java:234)
at
org.apache.jute.CsvOutputArchive.writeBuffer(CsvOutputArchive.java:101)
at
org.apache.zookeeper.proto.GetDataResponse.toString(GetDataResponse.java:48)
at java.lang.String.valueOf(String.java:2827)
at java.lang.StringBuilder.append(StringBuilder.java:115)
at
org.apache.zookeeper.ClientCnxn$Packet.toString(ClientCnxn.java:230)
at java.lang.String.valueOf(String.java:2827)
at java.lang.StringBuilder.append(StringBuilder.java:115)
at
org.apache.zookeeper.ClientCnxn$SendThread.readResponse(ClientCnxn.java:586)
at
org.apache.zookeeper.ClientCnxn$SendThread.doIO(ClientCnxn.java:626)
at
org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:852)
java.lang.NullPointerException
at org.apache.jute.Utils.toCSVBuffer(Utils.java:234)
at
org.apache.jute.CsvOutputArchive.writeBuffer(CsvOutputArchive.java:101)
at
org.apache.zookeeper.proto.GetDataResponse.toString(GetDataResponse.java:48)
at java.lang.String.valueOf(String.java:2827)
at java.lang.StringBuilder.append(StringBuilder.java:115)
at
org.apache.zookeeper.ClientCnxn$Packet.toString(ClientCnxn.java:230)
at java.lang.String.valueOf(String.java:2827)
at java.lang.StringBuilder.append(StringBuilder.java:115)
at
org.apache.zookeeper.ClientCnxn$SendThread.readResponse(ClientCnxn.java:586)
at
org.apache.zookeeper.ClientCnxn$SendThread.doIO(ClientCnxn.java:626)
at
org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:852)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-265) remove (deprecate) unused NoSyncConnected from KeeperState
[ https://issues.apache.org/jira/browse/ZOOKEEPER-265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12662118#action_12662118 ] Mahadev konar commented on ZOOKEEPER-265: - +1 on the patch. We should open a new jira to reomve the deprecated constants in the next release. remove (deprecate) unused NoSyncConnected from KeeperState -- Key: ZOOKEEPER-265 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-265 Project: Zookeeper Issue Type: Improvement Components: c client, java client, server Affects Versions: 3.0.0, 3.0.1 Reporter: Patrick Hunt Assignee: Patrick Hunt Priority: Minor Fix For: 3.1.0 Attachments: ZOOKEEPER-265.patch deprecate NoSyncConnected in KeeperState - it's not used anywhere in the codebase. what about Unknown? that seems to be unused as well, deprecate it as well? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-265) remove (deprecate) unused NoSyncConnected from KeeperState
[ https://issues.apache.org/jira/browse/ZOOKEEPER-265?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12662121#action_12662121 ] Mahadev konar commented on ZOOKEEPER-265: - I just created ZOOKEEPER-270. Ill commit this patch. remove (deprecate) unused NoSyncConnected from KeeperState -- Key: ZOOKEEPER-265 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-265 Project: Zookeeper Issue Type: Improvement Components: c client, java client, server Affects Versions: 3.0.0, 3.0.1 Reporter: Patrick Hunt Assignee: Patrick Hunt Priority: Minor Fix For: 3.1.0 Attachments: ZOOKEEPER-265.patch deprecate NoSyncConnected in KeeperState - it's not used anywhere in the codebase. what about Unknown? that seems to be unused as well, deprecate it as well? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-265) remove (deprecate) unused NoSyncConnected from KeeperState
[ https://issues.apache.org/jira/browse/ZOOKEEPER-265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mahadev konar updated ZOOKEEPER-265: Resolution: Fixed Hadoop Flags: [Reviewed] Status: Resolved (was: Patch Available) I just committed this. Thanks Pat. remove (deprecate) unused NoSyncConnected from KeeperState -- Key: ZOOKEEPER-265 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-265 Project: Zookeeper Issue Type: Improvement Components: c client, java client, server Affects Versions: 3.0.0, 3.0.1 Reporter: Patrick Hunt Assignee: Patrick Hunt Priority: Minor Fix For: 3.1.0 Attachments: ZOOKEEPER-265.patch deprecate NoSyncConnected in KeeperState - it's not used anywhere in the codebase. what about Unknown? that seems to be unused as well, deprecate it as well? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-266) KeeperState missing javadoc for values
[ https://issues.apache.org/jira/browse/ZOOKEEPER-266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mahadev konar updated ZOOKEEPER-266: Resolution: Fixed Status: Resolved (was: Patch Available) ZOOKEEPER-265 has been committed. KeeperState missing javadoc for values -- Key: ZOOKEEPER-266 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-266 Project: Zookeeper Issue Type: Bug Components: java client Affects Versions: 3.0.0, 3.0.1 Reporter: Patrick Hunt Assignee: Patrick Hunt Fix For: 3.1.0 KeeperState is missing documentation of the states. Should provide some basic details and refer users to the appropriate forrest doc for more detail (most likely prog guide). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-258) docs incorrectly state max client timeout as 60 seconds (it's based on server ticktime)
[
https://issues.apache.org/jira/browse/ZOOKEEPER-258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mahadev konar updated ZOOKEEPER-258:
Resolution: Fixed
Hadoop Flags: [Reviewed]
Status: Resolved (was: Patch Available)
I just committed this. Thanks pat.
docs incorrectly state max client timeout as 60 seconds (it's based on server
ticktime)
---
Key: ZOOKEEPER-258
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-258
Project: Zookeeper
Issue Type: Bug
Components: documentation
Affects Versions: 3.0.0, 3.0.1
Reporter: Patrick Hunt
Assignee: Patrick Hunt
Priority: Minor
Fix For: 3.1.0
Attachments: ZOOKEEPER-258.patch
The docs incorrectly state the max client timeout as 60 seconds.
http://hadoop.apache.org/zookeeper/docs/r3.0.1/zookeeperProgrammers.html#ch_zkSessions
the current server code has the following logic:
if (sessionTimeout zk.tickTime * 2) {
sessionTimeout = zk.tickTime * 2;
}
if (sessionTimeout zk.tickTime * 20) {
sessionTimeout = zk.tickTime * 20;
}
So really the docs should say max is 20*tickTime
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-135) Fat jar build target
[ https://issues.apache.org/jira/browse/ZOOKEEPER-135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mahadev konar updated ZOOKEEPER-135: Attachment: ZOOKEEPER-135.patch Fat jar build target Key: ZOOKEEPER-135 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-135 Project: Zookeeper Issue Type: New Feature Components: build Reporter: Benjamin Reed Assignee: Patrick Hunt Priority: Minor Fix For: 3.1.0 Attachments: ZOOKEEPER-135.patch, ZOOKEEPER-135.patch, ZOOKEEPER-135.patch, ZOOKEEPER-135.patch, ZOOKEEPER-135.patch For testing and experimentation purposes it would be nice to have everything in a self contained executable jar file that you can plop down on a machine and run. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-135) Fat jar build target
[ https://issues.apache.org/jira/browse/ZOOKEEPER-135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mahadev konar updated ZOOKEEPER-135: Resolution: Fixed Hadoop Flags: [Reviewed] Status: Resolved (was: Patch Available) I just committed this. Thanks pat and ben! Fat jar build target Key: ZOOKEEPER-135 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-135 Project: Zookeeper Issue Type: New Feature Components: build Reporter: Benjamin Reed Assignee: Patrick Hunt Priority: Minor Fix For: 3.1.0 Attachments: ZOOKEEPER-135.patch, ZOOKEEPER-135.patch, ZOOKEEPER-135.patch, ZOOKEEPER-135.patch, ZOOKEEPER-135.patch For testing and experimentation purposes it would be nice to have everything in a self contained executable jar file that you can plop down on a machine and run. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (ZOOKEEPER-271) Better command line parsing in ZookeeperMain.
Better command line parsing in ZookeeperMain. - Key: ZOOKEEPER-271 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-271 Project: Zookeeper Issue Type: Improvement Components: java client Affects Versions: 3.0.1, 3.0.0 Reporter: Mahadev konar Priority: Minor Fix For: 3.2.0 The command line parsing in zookeepermain is very basic.We should use some kind of cli parsing (commons-cli?) or something else that is standard and improve our command line parsing. This will remove the scattered code that we have in zookeepermain and we will have much better command line parsing. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-272) getChildren can fail for large numbers of children
[ https://issues.apache.org/jira/browse/ZOOKEEPER-272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12663422#action_12663422 ] Mahadev konar commented on ZOOKEEPER-272: - returning an offset for getchildren is a good suggestion should we just fix the limit in this jira and open another one for getchildren returning an offset ? fixing the limit would be easir to do and can be a part of 3.1 release. getChildren can fail for large numbers of children -- Key: ZOOKEEPER-272 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-272 Project: Zookeeper Issue Type: Bug Reporter: Joshua Tuberville Zookeeper allows creation of an abritrary number of children, yet if the String array of children names exceeds 4,194,304 bytes a getChildren will fail because ClientCnxn$SendThread.readLength() throws an exception on line 490. Mahadev Konar questioned this byte limit's need. In any case consistency of create children, get children should exist. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-231) Quotas in zookeeper
[ https://issues.apache.org/jira/browse/ZOOKEEPER-231?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mahadev konar updated ZOOKEEPER-231: Attachment: ZOOKEEPER-231.patch here is a more recent patch (needs testing). it does not include tests and docs -- will be adding them. Quotas in zookeeper --- Key: ZOOKEEPER-231 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-231 Project: Zookeeper Issue Type: New Feature Affects Versions: 3.0.0 Reporter: Mahadev konar Assignee: Mahadev konar Fix For: 3.1.0 Attachments: ZOOKEEPER-231.patch, ZOOKEEPER-231.patch creating quota's in zookeeper so that a runaway application does not bring down the zookeeper cluster. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-272) getChildren can fail for large numbers of children
[ https://issues.apache.org/jira/browse/ZOOKEEPER-272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mahadev konar updated ZOOKEEPER-272: Fix Version/s: 3.1.0 i think the limit should be fixed in 3.1 release and we can open a new jira for getchildren api getChildren can fail for large numbers of children -- Key: ZOOKEEPER-272 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-272 Project: Zookeeper Issue Type: Bug Reporter: Joshua Tuberville Fix For: 3.1.0 Zookeeper allows creation of an abritrary number of children, yet if the String array of children names exceeds 4,194,304 bytes a getChildren will fail because ClientCnxn$SendThread.readLength() throws an exception on line 490. Mahadev Konar questioned this byte limit's need. In any case consistency of create children, get children should exist. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-231) Quotas in zookeeper
[ https://issues.apache.org/jira/browse/ZOOKEEPER-231?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mahadev konar updated ZOOKEEPER-231: Attachment: ZOOKEEPER-231.patch updated patch ... shaked out some bugs... still needs tests and documentation... please review the code ill be making some changes but not drastic ones... the one thing to keep in mind is htat the current code forbids setting of quota if a path does not already exist (just an easier implementation choice) ... I will be changing that to setting of quota only if a path exists. Quotas in zookeeper --- Key: ZOOKEEPER-231 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-231 Project: Zookeeper Issue Type: New Feature Affects Versions: 3.0.0 Reporter: Mahadev konar Assignee: Mahadev konar Fix For: 3.1.0 Attachments: ZOOKEEPER-231.patch, ZOOKEEPER-231.patch, ZOOKEEPER-231.patch creating quota's in zookeeper so that a runaway application does not bring down the zookeeper cluster. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-231) Quotas in zookeeper
[ https://issues.apache.org/jira/browse/ZOOKEEPER-231?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mahadev konar updated ZOOKEEPER-231: Status: Patch Available (was: Open) Quotas in zookeeper --- Key: ZOOKEEPER-231 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-231 Project: Zookeeper Issue Type: New Feature Affects Versions: 3.0.0 Reporter: Mahadev konar Assignee: Mahadev konar Fix For: 3.1.0 Attachments: ZOOKEEPER-231.patch, ZOOKEEPER-231.patch, ZOOKEEPER-231.patch, ZOOKEEPER-231.patch creating quota's in zookeeper so that a runaway application does not bring down the zookeeper cluster. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-231) Quotas in zookeeper
[ https://issues.apache.org/jira/browse/ZOOKEEPER-231?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mahadev konar updated ZOOKEEPER-231: Attachment: ZOOKEEPER-231.patch this patch includes a test and documentation. The only thing I have to change is to allow setting quota only for paths athat exist. I will be adding more tests and more documentation. I will make it patch available to get early feedback.. Quotas in zookeeper --- Key: ZOOKEEPER-231 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-231 Project: Zookeeper Issue Type: New Feature Affects Versions: 3.0.0 Reporter: Mahadev konar Assignee: Mahadev konar Fix For: 3.1.0 Attachments: ZOOKEEPER-231.patch, ZOOKEEPER-231.patch, ZOOKEEPER-231.patch, ZOOKEEPER-231.patch creating quota's in zookeeper so that a runaway application does not bring down the zookeeper cluster. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-231) Quotas in zookeeper
[ https://issues.apache.org/jira/browse/ZOOKEEPER-231?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mahadev konar updated ZOOKEEPER-231: Attachment: ZOOKEEPER-231.patch fixed a bug that i found while debugging... Quotas in zookeeper --- Key: ZOOKEEPER-231 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-231 Project: Zookeeper Issue Type: New Feature Affects Versions: 3.0.0 Reporter: Mahadev konar Assignee: Mahadev konar Fix For: 3.1.0 Attachments: ZOOKEEPER-231.patch, ZOOKEEPER-231.patch, ZOOKEEPER-231.patch, ZOOKEEPER-231.patch, ZOOKEEPER-231.patch creating quota's in zookeeper so that a runaway application does not bring down the zookeeper cluster. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-231) Quotas in zookeeper
[ https://issues.apache.org/jira/browse/ZOOKEEPER-231?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mahadev konar updated ZOOKEEPER-231: Attachment: ZOOKEEPER-231.patch Here is the latest patch. THis patch has the following -- - quota can be set via the commadn line using setQuota -n|-b path - quota can be deleted via the commandline using delQuota [-n|-b] path - setting quota for a node that does not exist will throw an exception - setting quota for a node that has an ancestor or a descendant that has a quota cannot be set - includes a simeple test case -- their are lot of corner cases. I am still trying to add more - includes documentation (please review the documentation to see if you understand how to use quotas) - their are a lot of corner cases --- feel free to test them and mention it on the jira -- i will tru and write a test case for that. Quotas in zookeeper --- Key: ZOOKEEPER-231 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-231 Project: Zookeeper Issue Type: New Feature Affects Versions: 3.0.0 Reporter: Mahadev konar Assignee: Mahadev konar Fix For: 3.1.0 Attachments: ZOOKEEPER-231.patch, ZOOKEEPER-231.patch, ZOOKEEPER-231.patch, ZOOKEEPER-231.patch, ZOOKEEPER-231.patch, ZOOKEEPER-231.patch creating quota's in zookeeper so that a runaway application does not bring down the zookeeper cluster. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-231) Quotas in zookeeper
[ https://issues.apache.org/jira/browse/ZOOKEEPER-231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=1293#action_1293 ] Mahadev konar commented on ZOOKEEPER-231: - forogt to mention- - to list the quota limit and usage use listquota path Quotas in zookeeper --- Key: ZOOKEEPER-231 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-231 Project: Zookeeper Issue Type: New Feature Affects Versions: 3.0.0 Reporter: Mahadev konar Assignee: Mahadev konar Fix For: 3.1.0 Attachments: ZOOKEEPER-231.patch, ZOOKEEPER-231.patch, ZOOKEEPER-231.patch, ZOOKEEPER-231.patch, ZOOKEEPER-231.patch, ZOOKEEPER-231.patch creating quota's in zookeeper so that a runaway application does not bring down the zookeeper cluster. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-273) Zookeeper c client build should not depend on CPPUNIT
[ https://issues.apache.org/jira/browse/ZOOKEEPER-273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mahadev konar updated ZOOKEEPER-273: Resolution: Fixed Hadoop Flags: [Reviewed] Status: Resolved (was: Patch Available) I just committed this. Thanks pat and runping. Zookeeper c client build should not depend on CPPUNIT - Key: ZOOKEEPER-273 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-273 Project: Zookeeper Issue Type: Bug Components: c client Reporter: Runping Qi Assignee: Patrick Hunt Fix For: 3.1.0 Attachments: patch_zookeeper_273.txt, ZOOKEEPER-273.patch, ZOOKEEPER-273.patch One should be able to build Zookeeper C client libs on a machine without CPPUNIT installation. A simple fix is to remove from configure.ac the following line: M_PATH_CPPUNIT(1.10.2) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-268) tostring on jute generated objects can cause NPE
[ https://issues.apache.org/jira/browse/ZOOKEEPER-268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mahadev konar updated ZOOKEEPER-268: Resolution: Fixed Status: Resolved (was: Patch Available) I just committed this. Thanks pat. tostring on jute generated objects can cause NPE Key: ZOOKEEPER-268 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-268 Project: Zookeeper Issue Type: Bug Components: java client, server Affects Versions: 3.0.0, 3.0.1 Reporter: Patrick Hunt Assignee: Patrick Hunt Fix For: 3.1.0 Attachments: ZOOKEEPER-268.patch Jute still causing problems with tostring operations on generated code, need to review/cleanup the toCSV code From user Kevin Burton: - Creating this node with this ACL: Created /foo setAcl /foo world:anyone:w Causes the exception included below. It's an infinite loop so it's just called over and over again filling my console. I'm just doing an exists( path, true ); ... setting a watch still causes the problem. java.lang.NullPointerException at org.apache.jute.Utils.toCSVBuffer(Utils.java:234) at org.apache.jute.CsvOutputArchive.writeBuffer(CsvOutputArchive.java:101) at org.apache.zookeeper.proto.GetDataResponse.toString(GetDataResponse.java:48) at java.lang.String.valueOf(String.java:2827) at java.lang.StringBuilder.append(StringBuilder.java:115) at org.apache.zookeeper.ClientCnxn$Packet.toString(ClientCnxn.java:230) at java.lang.String.valueOf(String.java:2827) at java.lang.StringBuilder.append(StringBuilder.java:115) at org.apache.zookeeper.ClientCnxn$SendThread.readResponse(ClientCnxn.java:586) at org.apache.zookeeper.ClientCnxn$SendThread.doIO(ClientCnxn.java:626) at org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:852) java.lang.NullPointerException at org.apache.jute.Utils.toCSVBuffer(Utils.java:234) at org.apache.jute.CsvOutputArchive.writeBuffer(CsvOutputArchive.java:101) at org.apache.zookeeper.proto.GetDataResponse.toString(GetDataResponse.java:48) at java.lang.String.valueOf(String.java:2827) at java.lang.StringBuilder.append(StringBuilder.java:115) at org.apache.zookeeper.ClientCnxn$Packet.toString(ClientCnxn.java:230) at java.lang.String.valueOf(String.java:2827) at java.lang.StringBuilder.append(StringBuilder.java:115) at org.apache.zookeeper.ClientCnxn$SendThread.readResponse(ClientCnxn.java:586) at org.apache.zookeeper.ClientCnxn$SendThread.doIO(ClientCnxn.java:626) at org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:852) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-231) Quotas in zookeeper
[ https://issues.apache.org/jira/browse/ZOOKEEPER-231?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mahadev konar updated ZOOKEEPER-231: Attachment: ZOOKEEPER-231.patch added a junit test to run with QUorum for quotas. Quotas in zookeeper --- Key: ZOOKEEPER-231 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-231 Project: Zookeeper Issue Type: New Feature Affects Versions: 3.0.0 Reporter: Mahadev konar Assignee: Mahadev konar Fix For: 3.1.0 Attachments: ZOOKEEPER-231.patch, ZOOKEEPER-231.patch, ZOOKEEPER-231.patch, ZOOKEEPER-231.patch, ZOOKEEPER-231.patch, ZOOKEEPER-231.patch, ZOOKEEPER-231.patch creating quota's in zookeeper so that a runaway application does not bring down the zookeeper cluster. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-252) PurgeTxnLog is not handling the new dataDir directory structure
[ https://issues.apache.org/jira/browse/ZOOKEEPER-252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mahadev konar updated ZOOKEEPER-252: Attachment: ZOOKEEPER-252.patch this patch fixes the issue. It allows purgetxn to be called with -n num (which is to keep history for num snapshots). PurgeTxnLog is not handling the new dataDir directory structure --- Key: ZOOKEEPER-252 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-252 Project: Zookeeper Issue Type: Bug Components: server Affects Versions: 3.0.0, 3.0.1 Reporter: Patrick Hunt Assignee: Mahadev konar Priority: Critical Fix For: 3.1.0 Attachments: ZOOKEEPER-252.patch org.apache.zookeeper.server.PurgeTxnLog class has not been updated to handle the new directory structure imposed by the upgrade from v2 to v3 of ZooKeeper. In particular the dataDir now has a version-2 subdirectory that stores all of the snaps/transactionallogs for version2 of the persistence layer. I also note that the documentation of this class is particularly poor. I'm working on ZOOKEEPER-229 and would like to point to the API docs for this class regarding usage but they api docs are nonexistent Also - I think it's important for the user to be able to specify the number of backup snaps and logs that should be kept -- right now it seems we delete all but the current snaps/txlogs. Either by count or by date -- ie remove anything 5 days or older, with a minum of 3 most recents snaps (and accompanying txlogs) seems like a pretty common user case (assuming the operator is doing system backups every X days, etc...) in general this class needs some tlc - the formatting should also be cleaned up. Also - the API docs for this and LogFormatter are not included in the build.xml javadoc target. These are user utilities so javadoc for these two classes should be included. I will fix this issue as part of ZOOKEEPER-229. I'm also updateing the forrest documention in 229 so don't worry about that either. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (ZOOKEEPER-252) PurgeTxnLog is not handling the new dataDir directory structure
[ https://issues.apache.org/jira/browse/ZOOKEEPER-252?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12667552#action_12667552 ] mahadev edited comment on ZOOKEEPER-252 at 1/26/09 6:11 PM: -- this patch fixes the issue. It allows purgetxn to be called with -n num (which is to keep history for last n snapshots and the corresponding logs). was (Author: mahadev): this patch fixes the issue. It allows purgetxn to be called with -n num (which is to keep history for num snapshots). PurgeTxnLog is not handling the new dataDir directory structure --- Key: ZOOKEEPER-252 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-252 Project: Zookeeper Issue Type: Bug Components: server Affects Versions: 3.0.0, 3.0.1 Reporter: Patrick Hunt Assignee: Mahadev konar Priority: Critical Fix For: 3.1.0 Attachments: ZOOKEEPER-252.patch org.apache.zookeeper.server.PurgeTxnLog class has not been updated to handle the new directory structure imposed by the upgrade from v2 to v3 of ZooKeeper. In particular the dataDir now has a version-2 subdirectory that stores all of the snaps/transactionallogs for version2 of the persistence layer. I also note that the documentation of this class is particularly poor. I'm working on ZOOKEEPER-229 and would like to point to the API docs for this class regarding usage but they api docs are nonexistent Also - I think it's important for the user to be able to specify the number of backup snaps and logs that should be kept -- right now it seems we delete all but the current snaps/txlogs. Either by count or by date -- ie remove anything 5 days or older, with a minum of 3 most recents snaps (and accompanying txlogs) seems like a pretty common user case (assuming the operator is doing system backups every X days, etc...) in general this class needs some tlc - the formatting should also be cleaned up. Also - the API docs for this and LogFormatter are not included in the build.xml javadoc target. These are user utilities so javadoc for these two classes should be included. I will fix this issue as part of ZOOKEEPER-229. I'm also updateing the forrest documention in 229 so don't worry about that either. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-252) PurgeTxnLog is not handling the new dataDir directory structure
[ https://issues.apache.org/jira/browse/ZOOKEEPER-252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mahadev konar updated ZOOKEEPER-252: Attachment: (was: ZOOKEEPER-252.patch) PurgeTxnLog is not handling the new dataDir directory structure --- Key: ZOOKEEPER-252 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-252 Project: Zookeeper Issue Type: Bug Components: server Affects Versions: 3.0.0, 3.0.1 Reporter: Patrick Hunt Assignee: Mahadev konar Priority: Critical Fix For: 3.1.0 org.apache.zookeeper.server.PurgeTxnLog class has not been updated to handle the new directory structure imposed by the upgrade from v2 to v3 of ZooKeeper. In particular the dataDir now has a version-2 subdirectory that stores all of the snaps/transactionallogs for version2 of the persistence layer. I also note that the documentation of this class is particularly poor. I'm working on ZOOKEEPER-229 and would like to point to the API docs for this class regarding usage but they api docs are nonexistent Also - I think it's important for the user to be able to specify the number of backup snaps and logs that should be kept -- right now it seems we delete all but the current snaps/txlogs. Either by count or by date -- ie remove anything 5 days or older, with a minum of 3 most recents snaps (and accompanying txlogs) seems like a pretty common user case (assuming the operator is doing system backups every X days, etc...) in general this class needs some tlc - the formatting should also be cleaned up. Also - the API docs for this and LogFormatter are not included in the build.xml javadoc target. These are user utilities so javadoc for these two classes should be included. I will fix this issue as part of ZOOKEEPER-229. I'm also updateing the forrest documention in 229 so don't worry about that either. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-252) PurgeTxnLog is not handling the new dataDir directory structure
[ https://issues.apache.org/jira/browse/ZOOKEEPER-252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mahadev konar updated ZOOKEEPER-252: Attachment: ZOOKEEPER-252.patch had a bug in the last patch. PurgeTxnLog is not handling the new dataDir directory structure --- Key: ZOOKEEPER-252 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-252 Project: Zookeeper Issue Type: Bug Components: server Affects Versions: 3.0.0, 3.0.1 Reporter: Patrick Hunt Assignee: Mahadev konar Priority: Critical Fix For: 3.1.0 Attachments: ZOOKEEPER-252.patch org.apache.zookeeper.server.PurgeTxnLog class has not been updated to handle the new directory structure imposed by the upgrade from v2 to v3 of ZooKeeper. In particular the dataDir now has a version-2 subdirectory that stores all of the snaps/transactionallogs for version2 of the persistence layer. I also note that the documentation of this class is particularly poor. I'm working on ZOOKEEPER-229 and would like to point to the API docs for this class regarding usage but they api docs are nonexistent Also - I think it's important for the user to be able to specify the number of backup snaps and logs that should be kept -- right now it seems we delete all but the current snaps/txlogs. Either by count or by date -- ie remove anything 5 days or older, with a minum of 3 most recents snaps (and accompanying txlogs) seems like a pretty common user case (assuming the operator is doing system backups every X days, etc...) in general this class needs some tlc - the formatting should also be cleaned up. Also - the API docs for this and LogFormatter are not included in the build.xml javadoc target. These are user utilities so javadoc for these two classes should be included. I will fix this issue as part of ZOOKEEPER-229. I'm also updateing the forrest documention in 229 so don't worry about that either. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-264) docs should include a state transition diagram for client state
[ https://issues.apache.org/jira/browse/ZOOKEEPER-264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12667733#action_12667733 ] Mahadev konar commented on ZOOKEEPER-264: - http://wiki.apache.org/hadoop/ZooKeeper/FAQ is the link to the diagram... ben is tring to get it into the forrest docs for user docs. docs should include a state transition diagram for client state --- Key: ZOOKEEPER-264 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-264 Project: Zookeeper Issue Type: Improvement Components: documentation Affects Versions: 3.0.0, 3.0.1 Reporter: Patrick Hunt Assignee: Benjamin Reed Priority: Minor Fix For: 3.1.0 we should have a state transition diagram to help users understand client state transitions. perhaps the edges could indicate what might cause such a transition? (not sure if that will work). keep in mind for the states that the java/c clients have diff names for constants (not sure how to handle). This should be added to the programmer guide in the appropriate section. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-207) All the threads should have names so that its easier to see throguh a stack trace.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mahadev konar updated ZOOKEEPER-207: Fix Version/s: (was: 3.1.0) 3.2.0 moving to 3.2 All the threads should have names so that its easier to see throguh a stack trace. -- Key: ZOOKEEPER-207 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-207 Project: Zookeeper Issue Type: Improvement Components: server Affects Versions: 3.0.0 Reporter: Mahadev konar Assignee: Mahadev konar Priority: Minor Fix For: 3.2.0 the threads should have names so that its easier to look through the stack trace. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-196) doxygen comment for state argument of watcher_fn typedef and implementation differ (...one of the *_STATE constants, otherwise -1)
[ https://issues.apache.org/jira/browse/ZOOKEEPER-196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mahadev konar updated ZOOKEEPER-196: Fix Version/s: (was: 3.1.0) 3.2.0 moving it to 3.2 doxygen comment for state argument of watcher_fn typedef and implementation differ (...one of the *_STATE constants, otherwise -1) Key: ZOOKEEPER-196 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-196 Project: Zookeeper Issue Type: Bug Components: c client Environment: Linux Reporter: Maxim P. Dementiev Fix For: 3.2.0 In zookeeper.h: * \param state connection state. If the type is ZOO_SESSION_EVENT, the state value * will be one of the *_STATE constants, otherwise -1. but for this sequence: 1. zoo_awexists(name) 2. zoo_acreate(name) we've got a watcher callback with type=ZOO_CREATED_EVENT and state!=-1 I think the comment should be altered to underline the difference between zookeeper_init() callback usage and others (the getter API functions with the w prefix in their names) for the new watcher object style. It looks like the type and path argument values are useless for the former (because type is always ZOO_SESSION_EVENT, and path is always empty), and the state is useless for the latter (it is considered to be -1). And more, the state of the legacy style should be commented - will it be marked as obsolete? Or will it be supported in the future? I wonder if there are any plans to split current watcher_fn callback to something like: 1. new watcher_fn: typedef void (*watcher_fn)(zhandle_t *zh, int type, const char *path, void *watcherCtx); 2. connection_fn: typedef void (*watcher_fn)(zhandle_t *zh, int state, void *context); Because, you see, the usage is different and there is no any common set of arguments apart from zh (which is common for API) and context. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (ZOOKEEPER-229) improve documentation regarding user's responsibility to cleanup datadir (snaps/logs)
[ https://issues.apache.org/jira/browse/ZOOKEEPER-229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mahadev konar reassigned ZOOKEEPER-229: --- Assignee: Mahadev konar improve documentation regarding user's responsibility to cleanup datadir (snaps/logs) - Key: ZOOKEEPER-229 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-229 Project: Zookeeper Issue Type: Improvement Components: documentation, server Affects Versions: 3.0.0 Reporter: Patrick Hunt Assignee: Mahadev konar Fix For: 3.1.0 It's not very obvious in the docs that the operator of the zk server is responsible for managing the files in the datadir: http://hadoop.apache.org/zookeeper/docs/r3.0.0/zookeeperAdmin.html#File+Management specifically removing the old snaps/transactionallogs we need to make this more obvious, perhaps call it out in the quickstart (note pointing to this document) Perhaps we should include example script and cron as well (docs) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (ZOOKEEPER-272) getChildren can fail for large numbers of children
[ https://issues.apache.org/jira/browse/ZOOKEEPER-272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mahadev konar reassigned ZOOKEEPER-272: --- Assignee: Mahadev konar getChildren can fail for large numbers of children -- Key: ZOOKEEPER-272 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-272 Project: Zookeeper Issue Type: Bug Reporter: Joshua Tuberville Assignee: Mahadev konar Fix For: 3.1.0 Zookeeper allows creation of an abritrary number of children, yet if the String array of children names exceeds 4,194,304 bytes a getChildren will fail because ClientCnxn$SendThread.readLength() throws an exception on line 490. Mahadev Konar questioned this byte limit's need. In any case consistency of create children, get children should exist. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-233) Create a slimer jar for clients to reduce thier disk footprint.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mahadev konar updated ZOOKEEPER-233: Fix Version/s: (was: 3.1.0) 3.2.0 pushing it to 3.2 Create a slimer jar for clients to reduce thier disk footprint. --- Key: ZOOKEEPER-233 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-233 Project: Zookeeper Issue Type: New Feature Reporter: Hiram Chirino Priority: Trivial Fix For: 3.2.0 Patrick request I open up this in issue in this [email thread|http://n2.nabble.com/ActiveMQ-is-now-using-ZooKeeper-td1573272.html] -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-252) PurgeTxnLog is not handling the new dataDir directory structure
[ https://issues.apache.org/jira/browse/ZOOKEEPER-252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mahadev konar updated ZOOKEEPER-252: Attachment: ZOOKEEPER-252.patch this patch adds a test and checks to see we have exactly a given number of snapshots in the dir... PurgeTxnLog is not handling the new dataDir directory structure --- Key: ZOOKEEPER-252 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-252 Project: Zookeeper Issue Type: Bug Components: server Affects Versions: 3.0.0, 3.0.1 Reporter: Patrick Hunt Assignee: Mahadev konar Priority: Critical Fix For: 3.1.0 Attachments: ZOOKEEPER-252.patch, ZOOKEEPER-252.patch org.apache.zookeeper.server.PurgeTxnLog class has not been updated to handle the new directory structure imposed by the upgrade from v2 to v3 of ZooKeeper. In particular the dataDir now has a version-2 subdirectory that stores all of the snaps/transactionallogs for version2 of the persistence layer. I also note that the documentation of this class is particularly poor. I'm working on ZOOKEEPER-229 and would like to point to the API docs for this class regarding usage but they api docs are nonexistent Also - I think it's important for the user to be able to specify the number of backup snaps and logs that should be kept -- right now it seems we delete all but the current snaps/txlogs. Either by count or by date -- ie remove anything 5 days or older, with a minum of 3 most recents snaps (and accompanying txlogs) seems like a pretty common user case (assuming the operator is doing system backups every X days, etc...) in general this class needs some tlc - the formatting should also be cleaned up. Also - the API docs for this and LogFormatter are not included in the build.xml javadoc target. These are user utilities so javadoc for these two classes should be included. I will fix this issue as part of ZOOKEEPER-229. I'm also updateing the forrest documention in 229 so don't worry about that either. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-252) PurgeTxnLog is not handling the new dataDir directory structure
[ https://issues.apache.org/jira/browse/ZOOKEEPER-252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mahadev konar updated ZOOKEEPER-252: Status: Patch Available (was: Open) PurgeTxnLog is not handling the new dataDir directory structure --- Key: ZOOKEEPER-252 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-252 Project: Zookeeper Issue Type: Bug Components: server Affects Versions: 3.0.1, 3.0.0 Reporter: Patrick Hunt Assignee: Mahadev konar Priority: Critical Fix For: 3.1.0 Attachments: ZOOKEEPER-252.patch, ZOOKEEPER-252.patch, ZOOKEEPER-252.patch org.apache.zookeeper.server.PurgeTxnLog class has not been updated to handle the new directory structure imposed by the upgrade from v2 to v3 of ZooKeeper. In particular the dataDir now has a version-2 subdirectory that stores all of the snaps/transactionallogs for version2 of the persistence layer. I also note that the documentation of this class is particularly poor. I'm working on ZOOKEEPER-229 and would like to point to the API docs for this class regarding usage but they api docs are nonexistent Also - I think it's important for the user to be able to specify the number of backup snaps and logs that should be kept -- right now it seems we delete all but the current snaps/txlogs. Either by count or by date -- ie remove anything 5 days or older, with a minum of 3 most recents snaps (and accompanying txlogs) seems like a pretty common user case (assuming the operator is doing system backups every X days, etc...) in general this class needs some tlc - the formatting should also be cleaned up. Also - the API docs for this and LogFormatter are not included in the build.xml javadoc target. These are user utilities so javadoc for these two classes should be included. I will fix this issue as part of ZOOKEEPER-229. I'm also updateing the forrest documention in 229 so don't worry about that either. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-252) PurgeTxnLog is not handling the new dataDir directory structure
[ https://issues.apache.org/jira/browse/ZOOKEEPER-252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mahadev konar updated ZOOKEEPER-252: Attachment: ZOOKEEPER-252.patch fixed a minor bug. PurgeTxnLog is not handling the new dataDir directory structure --- Key: ZOOKEEPER-252 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-252 Project: Zookeeper Issue Type: Bug Components: server Affects Versions: 3.0.0, 3.0.1 Reporter: Patrick Hunt Assignee: Mahadev konar Priority: Critical Fix For: 3.1.0 Attachments: ZOOKEEPER-252.patch, ZOOKEEPER-252.patch, ZOOKEEPER-252.patch org.apache.zookeeper.server.PurgeTxnLog class has not been updated to handle the new directory structure imposed by the upgrade from v2 to v3 of ZooKeeper. In particular the dataDir now has a version-2 subdirectory that stores all of the snaps/transactionallogs for version2 of the persistence layer. I also note that the documentation of this class is particularly poor. I'm working on ZOOKEEPER-229 and would like to point to the API docs for this class regarding usage but they api docs are nonexistent Also - I think it's important for the user to be able to specify the number of backup snaps and logs that should be kept -- right now it seems we delete all but the current snaps/txlogs. Either by count or by date -- ie remove anything 5 days or older, with a minum of 3 most recents snaps (and accompanying txlogs) seems like a pretty common user case (assuming the operator is doing system backups every X days, etc...) in general this class needs some tlc - the formatting should also be cleaned up. Also - the API docs for this and LogFormatter are not included in the build.xml javadoc target. These are user utilities so javadoc for these two classes should be included. I will fix this issue as part of ZOOKEEPER-229. I'm also updateing the forrest documention in 229 so don't worry about that either. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-252) PurgeTxnLog is not handling the new dataDir directory structure
[ https://issues.apache.org/jira/browse/ZOOKEEPER-252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mahadev konar updated ZOOKEEPER-252: Attachment: ZOOKEEPER-252.patch missed the test. PurgeTxnLog is not handling the new dataDir directory structure --- Key: ZOOKEEPER-252 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-252 Project: Zookeeper Issue Type: Bug Components: server Affects Versions: 3.0.0, 3.0.1 Reporter: Patrick Hunt Assignee: Mahadev konar Priority: Critical Fix For: 3.1.0 Attachments: ZOOKEEPER-252.patch, ZOOKEEPER-252.patch, ZOOKEEPER-252.patch, ZOOKEEPER-252.patch org.apache.zookeeper.server.PurgeTxnLog class has not been updated to handle the new directory structure imposed by the upgrade from v2 to v3 of ZooKeeper. In particular the dataDir now has a version-2 subdirectory that stores all of the snaps/transactionallogs for version2 of the persistence layer. I also note that the documentation of this class is particularly poor. I'm working on ZOOKEEPER-229 and would like to point to the API docs for this class regarding usage but they api docs are nonexistent Also - I think it's important for the user to be able to specify the number of backup snaps and logs that should be kept -- right now it seems we delete all but the current snaps/txlogs. Either by count or by date -- ie remove anything 5 days or older, with a minum of 3 most recents snaps (and accompanying txlogs) seems like a pretty common user case (assuming the operator is doing system backups every X days, etc...) in general this class needs some tlc - the formatting should also be cleaned up. Also - the API docs for this and LogFormatter are not included in the build.xml javadoc target. These are user utilities so javadoc for these two classes should be included. I will fix this issue as part of ZOOKEEPER-229. I'm also updateing the forrest documention in 229 so don't worry about that either. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-177) needed: docs for JMX
[ https://issues.apache.org/jira/browse/ZOOKEEPER-177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mahadev konar updated ZOOKEEPER-177: Resolution: Fixed Hadoop Flags: [Reviewed] Status: Resolved (was: Patch Available) I just committed this. Thanks pat. needed: docs for JMX Key: ZOOKEEPER-177 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-177 Project: Zookeeper Issue Type: Improvement Components: documentation, jmx Reporter: Robbie Scott Assignee: Patrick Hunt Fix For: 3.1.0 Attachments: ZOOKEEPER-177.patch I don't know if this should be part of the logging section in the zookeeper admin guide (see JIRA ZOOKEEPER-166 ) but, per Patrick, related to security, ack, yea another doc, is the documentation of the JMX support that zk has -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-231) Quotas in zookeeper
[ https://issues.apache.org/jira/browse/ZOOKEEPER-231?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mahadev konar updated ZOOKEEPER-231: Attachment: ZOOKEEPER-231.patch Refactored the QuorumTest to create a quorumBase class like clientbase. Had to make some changes in the testcases to get it to working after the refactoring. Quotas in zookeeper --- Key: ZOOKEEPER-231 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-231 Project: Zookeeper Issue Type: New Feature Affects Versions: 3.0.0 Reporter: Mahadev konar Assignee: Mahadev konar Fix For: 3.1.0 Attachments: ZOOKEEPER-231.patch, ZOOKEEPER-231.patch, ZOOKEEPER-231.patch, ZOOKEEPER-231.patch, ZOOKEEPER-231.patch, ZOOKEEPER-231.patch, ZOOKEEPER-231.patch, ZOOKEEPER-231.patch creating quota's in zookeeper so that a runaway application does not bring down the zookeeper cluster. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-229) improve documentation regarding user's responsibility to cleanup datadir (snaps/logs)
[ https://issues.apache.org/jira/browse/ZOOKEEPER-229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mahadev konar updated ZOOKEEPER-229: Attachment: ZOOKEEPER-229.patch this patch adds appropriate docs to getting started and zookeeperadmin. improve documentation regarding user's responsibility to cleanup datadir (snaps/logs) - Key: ZOOKEEPER-229 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-229 Project: Zookeeper Issue Type: Improvement Components: documentation, server Affects Versions: 3.0.0 Reporter: Patrick Hunt Assignee: Mahadev konar Fix For: 3.1.0 Attachments: ZOOKEEPER-229.patch It's not very obvious in the docs that the operator of the zk server is responsible for managing the files in the datadir: http://hadoop.apache.org/zookeeper/docs/r3.0.0/zookeeperAdmin.html#File+Management specifically removing the old snaps/transactionallogs we need to make this more obvious, perhaps call it out in the quickstart (note pointing to this document) Perhaps we should include example script and cron as well (docs) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-229) improve documentation regarding user's responsibility to cleanup datadir (snaps/logs)
[ https://issues.apache.org/jira/browse/ZOOKEEPER-229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mahadev konar updated ZOOKEEPER-229: Status: Patch Available (was: Open) improve documentation regarding user's responsibility to cleanup datadir (snaps/logs) - Key: ZOOKEEPER-229 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-229 Project: Zookeeper Issue Type: Improvement Components: documentation, server Affects Versions: 3.0.0 Reporter: Patrick Hunt Assignee: Mahadev konar Fix For: 3.1.0 Attachments: ZOOKEEPER-229.patch It's not very obvious in the docs that the operator of the zk server is responsible for managing the files in the datadir: http://hadoop.apache.org/zookeeper/docs/r3.0.0/zookeeperAdmin.html#File+Management specifically removing the old snaps/transactionallogs we need to make this more obvious, perhaps call it out in the quickstart (note pointing to this document) Perhaps we should include example script and cron as well (docs) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-272) getChildren can fail for large numbers of children
[ https://issues.apache.org/jira/browse/ZOOKEEPER-272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mahadev konar updated ZOOKEEPER-272: Attachment: ZOOKEEPER-272.patch this patch allows tthe user to set java property jute.maxbuffer at the client. This value is used at the client to throw an error if the read len of value exceeds the set value. By default its set to 4MB. if the user wants to cahnge this value, he can do it via setting java property -Djute.maxbuffer=someintvalue getChildren can fail for large numbers of children -- Key: ZOOKEEPER-272 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-272 Project: Zookeeper Issue Type: Bug Reporter: Joshua Tuberville Assignee: Mahadev konar Fix For: 3.1.0 Attachments: ZOOKEEPER-272.patch Zookeeper allows creation of an abritrary number of children, yet if the String array of children names exceeds 4,194,304 bytes a getChildren will fail because ClientCnxn$SendThread.readLength() throws an exception on line 490. Mahadev Konar questioned this byte limit's need. In any case consistency of create children, get children should exist. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-272) getChildren can fail for large numbers of children
[ https://issues.apache.org/jira/browse/ZOOKEEPER-272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mahadev konar updated ZOOKEEPER-272: Status: Patch Available (was: Open) getChildren can fail for large numbers of children -- Key: ZOOKEEPER-272 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-272 Project: Zookeeper Issue Type: Bug Reporter: Joshua Tuberville Assignee: Mahadev konar Fix For: 3.1.0 Attachments: ZOOKEEPER-272.patch Zookeeper allows creation of an abritrary number of children, yet if the String array of children names exceeds 4,194,304 bytes a getChildren will fail because ClientCnxn$SendThread.readLength() throws an exception on line 490. Mahadev Konar questioned this byte limit's need. In any case consistency of create children, get children should exist. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-260) document the recommended values for server id's
[ https://issues.apache.org/jira/browse/ZOOKEEPER-260?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mahadev konar updated ZOOKEEPER-260: Status: Patch Available (was: Open) document the recommended values for server id's --- Key: ZOOKEEPER-260 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-260 Project: Zookeeper Issue Type: Improvement Affects Versions: 3.0.1, 3.0.0 Reporter: Mahadev konar Assignee: Mahadev konar Fix For: 3.1.0 Attachments: ZOOKEEPER-260.patch currently we do nto doucment the recommended values for server id's. we should document that. For some large values of server id's we might get negative session's and also might get duplicate sessions from two servers. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-260) document the recommended values for server id's
[ https://issues.apache.org/jira/browse/ZOOKEEPER-260?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mahadev konar updated ZOOKEEPER-260: Attachment: ZOOKEEPER-260.patch this patch adds docs for recommended values of server ids. document the recommended values for server id's --- Key: ZOOKEEPER-260 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-260 Project: Zookeeper Issue Type: Improvement Affects Versions: 3.0.0, 3.0.1 Reporter: Mahadev konar Assignee: Mahadev konar Fix For: 3.1.0 Attachments: ZOOKEEPER-260.patch currently we do nto doucment the recommended values for server id's. we should document that. For some large values of server id's we might get negative session's and also might get duplicate sessions from two servers. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-272) getChildren can fail for large numbers of children
[ https://issues.apache.org/jira/browse/ZOOKEEPER-272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12668373#action_12668373 ] Mahadev konar commented on ZOOKEEPER-272: - sorry i should have mentioned this earlier. I planned to open a jira for exactly what you mentioned above. Thsi fix is a quick fix for the upcoming release. getChildren can fail for large numbers of children -- Key: ZOOKEEPER-272 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-272 Project: Zookeeper Issue Type: Bug Reporter: Joshua Tuberville Assignee: Mahadev konar Fix For: 3.1.0 Attachments: ZOOKEEPER-272.patch Zookeeper allows creation of an abritrary number of children, yet if the String array of children names exceeds 4,194,304 bytes a getChildren will fail because ClientCnxn$SendThread.readLength() throws an exception on line 490. Mahadev Konar questioned this byte limit's need. In any case consistency of create children, get children should exist. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-275) Bug in FastLeaderElection
[ https://issues.apache.org/jira/browse/ZOOKEEPER-275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mahadev konar updated ZOOKEEPER-275: Status: Open (was: Patch Available) the patch does not apply any mroe. I tried creating a new patch but its a little tricky so I didnt want to mess up the patch. Can you regenerate the patch Flavio? Bug in FastLeaderElection - Key: ZOOKEEPER-275 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-275 Project: Zookeeper Issue Type: Bug Components: leaderElection Affects Versions: 3.0.1, 3.0.0 Reporter: Flavio Paiva Junqueira Assignee: Flavio Paiva Junqueira Fix For: 3.1.0 Attachments: ZOOKEEPER-275.patch I found an execution in which leader election does not make progress. Here is the problematic scenario: - We have an ensemble of 3 servers, and we start only 2; - We let them elect a leader, and then crash the one with lowest id, say S_1 (call the other S_2); - We restart the crashed server. Upon restarting S_1, S_2 has its logical clock more advanced, and S_1 has its logical clock set to 1. Once S_1 receives a notification from S_2, it notices that it is in the wrong round and it advances its logical clock to the same value as S_1. Now, the problem comes exactly in this point because in the current code S_1 resets its vote to its initial vote (its own id and zxid). Since S_2 has already notified S_1, it won't do it again, and we are stuck. The patch I'm submitting fixes this problem by setting the vote of S_1 to the one received if it satisfies the total order predicate (received zxid is higher or received zxid is the same and received id is higher). Related to this problem, I noticed that by trying to avoid unnecessary notification duplicates, there could be scenarios in which a server fails before electing a leader and restarts before leader election succeeds. This could happen, for example, when there isn't enough servers available and one available crashes and restarts. I fixed this problem in the attached patch by allowing a server to send a new batch of notifications if there is at least one outgoing queue of pending notifications empty. This is ok because we space out consecutive batches of notifications. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-275) Bug in FastLeaderElection
[ https://issues.apache.org/jira/browse/ZOOKEEPER-275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mahadev konar updated ZOOKEEPER-275: Attachment: ZOOKEEPER-275.patch fixed some log.info to be log.debug and fixed the duplicated log messages as well. Bug in FastLeaderElection - Key: ZOOKEEPER-275 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-275 Project: Zookeeper Issue Type: Bug Components: leaderElection Affects Versions: 3.0.0, 3.0.1 Reporter: Flavio Paiva Junqueira Assignee: Flavio Paiva Junqueira Fix For: 3.1.0 Attachments: ZOOKEEPER-275.patch, ZOOKEEPER-275.patch, ZOOKEEPER-275.patch I found an execution in which leader election does not make progress. Here is the problematic scenario: - We have an ensemble of 3 servers, and we start only 2; - We let them elect a leader, and then crash the one with lowest id, say S_1 (call the other S_2); - We restart the crashed server. Upon restarting S_1, S_2 has its logical clock more advanced, and S_1 has its logical clock set to 1. Once S_1 receives a notification from S_2, it notices that it is in the wrong round and it advances its logical clock to the same value as S_1. Now, the problem comes exactly in this point because in the current code S_1 resets its vote to its initial vote (its own id and zxid). Since S_2 has already notified S_1, it won't do it again, and we are stuck. The patch I'm submitting fixes this problem by setting the vote of S_1 to the one received if it satisfies the total order predicate (received zxid is higher or received zxid is the same and received id is higher). Related to this problem, I noticed that by trying to avoid unnecessary notification duplicates, there could be scenarios in which a server fails before electing a leader and restarts before leader election succeeds. This could happen, for example, when there isn't enough servers available and one available crashes and restarts. I fixed this problem in the attached patch by allowing a server to send a new batch of notifications if there is at least one outgoing queue of pending notifications empty. This is ok because we space out consecutive batches of notifications. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-275) Bug in FastLeaderElection
[ https://issues.apache.org/jira/browse/ZOOKEEPER-275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mahadev konar updated ZOOKEEPER-275: Attachment: ZOOKEEPER-275.patch the last patches fail with compile-test since one of the test uses an old api. Bug in FastLeaderElection - Key: ZOOKEEPER-275 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-275 Project: Zookeeper Issue Type: Bug Components: leaderElection Affects Versions: 3.0.0, 3.0.1 Reporter: Flavio Paiva Junqueira Assignee: Flavio Paiva Junqueira Fix For: 3.1.0 Attachments: ZOOKEEPER-275.patch, ZOOKEEPER-275.patch, ZOOKEEPER-275.patch, ZOOKEEPER-275.patch I found an execution in which leader election does not make progress. Here is the problematic scenario: - We have an ensemble of 3 servers, and we start only 2; - We let them elect a leader, and then crash the one with lowest id, say S_1 (call the other S_2); - We restart the crashed server. Upon restarting S_1, S_2 has its logical clock more advanced, and S_1 has its logical clock set to 1. Once S_1 receives a notification from S_2, it notices that it is in the wrong round and it advances its logical clock to the same value as S_1. Now, the problem comes exactly in this point because in the current code S_1 resets its vote to its initial vote (its own id and zxid). Since S_2 has already notified S_1, it won't do it again, and we are stuck. The patch I'm submitting fixes this problem by setting the vote of S_1 to the one received if it satisfies the total order predicate (received zxid is higher or received zxid is the same and received id is higher). Related to this problem, I noticed that by trying to avoid unnecessary notification duplicates, there could be scenarios in which a server fails before electing a leader and restarts before leader election succeeds. This could happen, for example, when there isn't enough servers available and one available crashes and restarts. I fixed this problem in the attached patch by allowing a server to send a new batch of notifications if there is at least one outgoing queue of pending notifications empty. This is ok because we space out consecutive batches of notifications. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-275) Bug in FastLeaderElection
[ https://issues.apache.org/jira/browse/ZOOKEEPER-275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mahadev konar updated ZOOKEEPER-275: Resolution: Fixed Hadoop Flags: [Reviewed] Status: Resolved (was: Patch Available) I just committed this. Thanks flavio. Bug in FastLeaderElection - Key: ZOOKEEPER-275 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-275 Project: Zookeeper Issue Type: Bug Components: leaderElection Affects Versions: 3.0.0, 3.0.1 Reporter: Flavio Paiva Junqueira Assignee: Flavio Paiva Junqueira Fix For: 3.1.0 Attachments: ZOOKEEPER-275.patch, ZOOKEEPER-275.patch, ZOOKEEPER-275.patch, ZOOKEEPER-275.patch I found an execution in which leader election does not make progress. Here is the problematic scenario: - We have an ensemble of 3 servers, and we start only 2; - We let them elect a leader, and then crash the one with lowest id, say S_1 (call the other S_2); - We restart the crashed server. Upon restarting S_1, S_2 has its logical clock more advanced, and S_1 has its logical clock set to 1. Once S_1 receives a notification from S_2, it notices that it is in the wrong round and it advances its logical clock to the same value as S_1. Now, the problem comes exactly in this point because in the current code S_1 resets its vote to its initial vote (its own id and zxid). Since S_2 has already notified S_1, it won't do it again, and we are stuck. The patch I'm submitting fixes this problem by setting the vote of S_1 to the one received if it satisfies the total order predicate (received zxid is higher or received zxid is the same and received id is higher). Related to this problem, I noticed that by trying to avoid unnecessary notification duplicates, there could be scenarios in which a server fails before electing a leader and restarts before leader election succeeds. This could happen, for example, when there isn't enough servers available and one available crashes and restarts. I fixed this problem in the attached patch by allowing a server to send a new batch of notifications if there is at least one outgoing queue of pending notifications empty. This is ok because we space out consecutive batches of notifications. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-269) connectionloss - add more documentation to detail
[ https://issues.apache.org/jira/browse/ZOOKEEPER-269?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mahadev konar updated ZOOKEEPER-269: Resolution: Fixed Hadoop Flags: [Reviewed] Status: Resolved (was: Patch Available) I just committed this. Thanks flavio and pat. connectionloss - add more documentation to detail -- Key: ZOOKEEPER-269 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-269 Project: Zookeeper Issue Type: Improvement Components: documentation Affects Versions: 3.0.0, 3.0.1 Reporter: Patrick Hunt Assignee: Flavio Paiva Junqueira Priority: Minor Fix For: 3.1.0 Attachments: ZOOKEEPER-269.patch, ZOOKEEPER-269.patch, ZOOKEEPER-269.patch discussion with user, this should be better documented: -- There are basically 2 cases where you can see connectionloss: 1) you call an operation on a session that is no longer alive 2) you are disconnected from a server when there are pending async operations to that server (you made an async request which has not yet completed) Patrick Kevin Burton wrote: Can this be thrown when using multiple servers as long as 1 of them is online? Trying to figure out of I should try some type of reconnect if a single machine fails instead of failing altogether. Kevin -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-262) unnecesssarily complex reentrant zookeeper_close() logic
[ https://issues.apache.org/jira/browse/ZOOKEEPER-262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mahadev konar updated ZOOKEEPER-262: Fix Version/s: (was: 4.0.0) (was: 3.1.0) moving this jira to the next release. this is not a blocker for 3.1 release. unnecesssarily complex reentrant zookeeper_close() logic Key: ZOOKEEPER-262 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-262 Project: Zookeeper Issue Type: Improvement Components: c client Affects Versions: 3.0.0, 3.0.1, 3.1.0, 3.2.0, 4.0.0 Reporter: Chris Darroch Priority: Minor Fix For: 3.2.0 Attachments: zookeeper-close.patch While working on a wrapper for the C API I puzzled over the problem of how to determine when the multi-threaded adaptor's IO and completion threads had exited. Looking at the code in api_epilog() and adaptor_finish() it seemed clear that any thread could be the last one out the door, and whichever was last would turn out the lights by calling zookeeper_close(). However, on further examination I found that in fact, the close_requested flag guards entry to zookeeper_close() in api_epilog(), and close_requested can only be set non-zero within zookeeper_close(). Thus, only the user's main thread can invoke zookeeper_close() and kick off the shutdown process. When that happens, zookeeper_close() then invokes adaptor_finish() and returns ZOK immediately afterward. Since adaptor_finish() is only called in this one context, it means all the code in that function to check pthread_self() and call pthread_detach() if the current thread is the IO or completion thread is redundant. The adaptor_finish() function always signals and then waits to join with the IO and completion threads because it can only be called by the user's main thread. After joining with the two internal threads, adaptor_finish() calls api_epilog(), which might seem like a trivial final action. However, this is actually where all the work gets done, because in this one case, api_epilog() sees a non-zero close_requested flag value and invokes zookeeper_close(). Note that zookeeper_close() is already on the stack; this is a re-entrant invocation. This time around, zookeeper_close() skips the call to adaptor_finish() -- assuming the reference count has been properly decremented to zero! -- and does the actual final cleanup steps, including deallocating the zh structure. Fortunately, none of the callers on the stack (api_epilog(), adaptor_finish(), and the first zookeeper_close()) touches zh after this. This all works OK, and in particular, the fact that I can be certain that the IO and completion threads have exited after zookeeper_close() returns is great. So too is the fact that those threads can't invoke zookeeper_close() without my knowing about it. However, the actual mechanics of the shutdown seem unnecessarily complex. I'd be worried a bit about a new maintainer looking at adaptor_finish() and reasonably concluding that it can be called by any thread, including the IO and completion ones. Or thinking that the zh handle can still be used after that innocuous-looking call to adaptor_finish() in zookeeper_close() -- the one that actually causes all the work to be done and the handle to be deallocated! I'll attach a patch which I think simplifies the code a bit and makes the shutdown mechanics a little more clear, and might prevent unintentional errors in the future. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-276) Bookkeeper contribution
[
https://issues.apache.org/jira/browse/ZOOKEEPER-276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12668718#action_12668718
]
Mahadev konar commented on ZOOKEEPER-276:
-
also ant tar on top level dir gives the following error -
{noformat}
compile:
[echo] contrib: bookkeeper
[javac] Compiling 26 source files to
/Users/mahadev/workspace/zookeeper-commit-trunk/build/contrib/bookkeeper/classes
[javac]
/Users/mahadev/workspace/zookeeper-commit-trunk/src/contrib/bookkeeper/src/java/org/apache/bookkeeper/bookie/Bookie.java:302:
method does not override a method from its superclass
[javac] @Override
[javac] ^
[javac]
/Users/mahadev/workspace/zookeeper-commit-trunk/src/contrib/bookkeeper/src/java/org/apache/bookkeeper/proto/BookieClient.java:317:
method does not override a method from its superclass
[javac] @Override
[javac] ^
[javac]
/Users/mahadev/workspace/zookeeper-commit-trunk/src/contrib/bookkeeper/src/java/org/apache/bookkeeper/proto/BookieServer.java:87:
method does not override a method from its superclass
[javac] @Override
[javac] ^
[javac]
/Users/mahadev/workspace/zookeeper-commit-trunk/src/contrib/bookkeeper/src/java/org/apache/bookkeeper/proto/BookieServer.java:164:
method does not override a method from its superclass
[javac] @Override
[javac] ^
[javac]
/Users/mahadev/workspace/zookeeper-commit-trunk/src/contrib/bookkeeper/src/java/org/apache/bookkeeper/util/LocalBookKeeper.java:143:
method does not override a method from its superclass
[javac] @Override
[javac] ^
[javac] 5 errors
{noformat}
Bookkeeper contribution
---
Key: ZOOKEEPER-276
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-276
Project: Zookeeper
Issue Type: New Feature
Reporter: Luca Telloli
Assignee: Flavio Paiva Junqueira
Fix For: 3.1.0
Attachments: ZOOKEEPER-276.patch, ZOOKEEPER-276.patch,
ZOOKEEPER-276.patch, ZOOKEEPER-276.patch
BookKeeper is a system to reliably log streams of records. In BookKeeper,
servers are bookies, log streams are ledgers, and each unit of a log (aka
record) is a ledger entry. BookKeeper is designed to be reliable; bookies,
the servers that store ledgers can be byzantine, which means that some subset
of the bookies can fail, corrupt data, discard data, but as long as there are
enough correctly behaving servers the service as a whole behaves correctly;
the meta data for BookKeeper is stored in ZooKeeper.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (ZOOKEEPER-276) Bookkeeper contribution
[
https://issues.apache.org/jira/browse/ZOOKEEPER-276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12668718#action_12668718
]
mahadev edited comment on ZOOKEEPER-276 at 1/29/09 6:50 PM:
--
also ant tar on top level dir fails with the following error -
{noformat}
compile:
[echo] contrib: bookkeeper
[javac] Compiling 26 source files to
/Users/mahadev/workspace/zookeeper-commit-trunk/build/contrib/bookkeeper/classes
[javac]
/Users/mahadev/workspace/zookeeper-commit-trunk/src/contrib/bookkeeper/src/java/org/apache/bookkeeper/bookie/Bookie.java:302:
method does not override a method from its superclass
[javac] @Override
[javac] ^
[javac]
/Users/mahadev/workspace/zookeeper-commit-trunk/src/contrib/bookkeeper/src/java/org/apache/bookkeeper/proto/BookieClient.java:317:
method does not override a method from its superclass
[javac] @Override
[javac] ^
[javac]
/Users/mahadev/workspace/zookeeper-commit-trunk/src/contrib/bookkeeper/src/java/org/apache/bookkeeper/proto/BookieServer.java:87:
method does not override a method from its superclass
[javac] @Override
[javac] ^
[javac]
/Users/mahadev/workspace/zookeeper-commit-trunk/src/contrib/bookkeeper/src/java/org/apache/bookkeeper/proto/BookieServer.java:164:
method does not override a method from its superclass
[javac] @Override
[javac] ^
[javac]
/Users/mahadev/workspace/zookeeper-commit-trunk/src/contrib/bookkeeper/src/java/org/apache/bookkeeper/util/LocalBookKeeper.java:143:
method does not override a method from its superclass
[javac] @Override
[javac] ^
[javac] 5 errors
{noformat}
was (Author: mahadev):
also ant tar on top level dir gives the following error -
{noformat}
compile:
[echo] contrib: bookkeeper
[javac] Compiling 26 source files to
/Users/mahadev/workspace/zookeeper-commit-trunk/build/contrib/bookkeeper/classes
[javac]
/Users/mahadev/workspace/zookeeper-commit-trunk/src/contrib/bookkeeper/src/java/org/apache/bookkeeper/bookie/Bookie.java:302:
method does not override a method from its superclass
[javac] @Override
[javac] ^
[javac]
/Users/mahadev/workspace/zookeeper-commit-trunk/src/contrib/bookkeeper/src/java/org/apache/bookkeeper/proto/BookieClient.java:317:
method does not override a method from its superclass
[javac] @Override
[javac] ^
[javac]
/Users/mahadev/workspace/zookeeper-commit-trunk/src/contrib/bookkeeper/src/java/org/apache/bookkeeper/proto/BookieServer.java:87:
method does not override a method from its superclass
[javac] @Override
[javac] ^
[javac]
/Users/mahadev/workspace/zookeeper-commit-trunk/src/contrib/bookkeeper/src/java/org/apache/bookkeeper/proto/BookieServer.java:164:
method does not override a method from its superclass
[javac] @Override
[javac] ^
[javac]
/Users/mahadev/workspace/zookeeper-commit-trunk/src/contrib/bookkeeper/src/java/org/apache/bookkeeper/util/LocalBookKeeper.java:143:
method does not override a method from its superclass
[javac] @Override
[javac] ^
[javac] 5 errors
{noformat}
Bookkeeper contribution
---
Key: ZOOKEEPER-276
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-276
Project: Zookeeper
Issue Type: New Feature
Reporter: Luca Telloli
Assignee: Flavio Paiva Junqueira
Fix For: 3.1.0
Attachments: ZOOKEEPER-276.patch, ZOOKEEPER-276.patch,
ZOOKEEPER-276.patch, ZOOKEEPER-276.patch
BookKeeper is a system to reliably log streams of records. In BookKeeper,
servers are bookies, log streams are ledgers, and each unit of a log (aka
record) is a ledger entry. BookKeeper is designed to be reliable; bookies,
the servers that store ledgers can be byzantine, which means that some subset
of the bookies can fail, corrupt data, discard data, but as long as there are
enough correctly behaving servers the service as a whole behaves correctly;
the meta data for BookKeeper is stored in ZooKeeper.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-276) Bookkeeper contribution
[ https://issues.apache.org/jira/browse/ZOOKEEPER-276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mahadev konar updated ZOOKEEPER-276: Attachment: ZOOKEEPER-276.patch fixed license on oen of the files... and fixed bookkeeper tests ... (they had @override tags which were nto required.) Bookkeeper contribution --- Key: ZOOKEEPER-276 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-276 Project: Zookeeper Issue Type: New Feature Reporter: Luca Telloli Assignee: Flavio Paiva Junqueira Fix For: 3.1.0 Attachments: ZOOKEEPER-276.patch, ZOOKEEPER-276.patch, ZOOKEEPER-276.patch, ZOOKEEPER-276.patch, ZOOKEEPER-276.patch, ZOOKEEPER-276.patch, ZOOKEEPER-276.patch BookKeeper is a system to reliably log streams of records. In BookKeeper, servers are bookies, log streams are ledgers, and each unit of a log (aka record) is a ledger entry. BookKeeper is designed to be reliable; bookies, the servers that store ledgers can be byzantine, which means that some subset of the bookies can fail, corrupt data, discard data, but as long as there are enough correctly behaving servers the service as a whole behaves correctly; the meta data for BookKeeper is stored in ZooKeeper. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-276) Bookkeeper contribution
[ https://issues.apache.org/jira/browse/ZOOKEEPER-276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12668991#action_12668991 ] Mahadev konar commented on ZOOKEEPER-276: - +1 on the patch .. the patch has tests and readme. some more javadocs would be great but we can fix that later. ill commit this for now. Bookkeeper contribution --- Key: ZOOKEEPER-276 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-276 Project: Zookeeper Issue Type: New Feature Reporter: Luca Telloli Assignee: Flavio Paiva Junqueira Fix For: 3.1.0 Attachments: ZOOKEEPER-276.patch, ZOOKEEPER-276.patch, ZOOKEEPER-276.patch, ZOOKEEPER-276.patch, ZOOKEEPER-276.patch, ZOOKEEPER-276.patch, ZOOKEEPER-276.patch BookKeeper is a system to reliably log streams of records. In BookKeeper, servers are bookies, log streams are ledgers, and each unit of a log (aka record) is a ledger entry. BookKeeper is designed to be reliable; bookies, the servers that store ledgers can be byzantine, which means that some subset of the bookies can fail, corrupt data, discard data, but as long as there are enough correctly behaving servers the service as a whole behaves correctly; the meta data for BookKeeper is stored in ZooKeeper. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-276) Bookkeeper contribution
[ https://issues.apache.org/jira/browse/ZOOKEEPER-276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mahadev konar updated ZOOKEEPER-276: Resolution: Fixed Hadoop Flags: [Reviewed] Status: Resolved (was: Patch Available) I just committed this. Thanks Luca and Flavio. Bookkeeper contribution --- Key: ZOOKEEPER-276 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-276 Project: Zookeeper Issue Type: New Feature Reporter: Luca Telloli Assignee: Flavio Paiva Junqueira Fix For: 3.1.0 Attachments: ZOOKEEPER-276.patch, ZOOKEEPER-276.patch, ZOOKEEPER-276.patch, ZOOKEEPER-276.patch, ZOOKEEPER-276.patch, ZOOKEEPER-276.patch, ZOOKEEPER-276.patch BookKeeper is a system to reliably log streams of records. In BookKeeper, servers are bookies, log streams are ledgers, and each unit of a log (aka record) is a ledger entry. BookKeeper is designed to be reliable; bookies, the servers that store ledgers can be byzantine, which means that some subset of the bookies can fail, corrupt data, discard data, but as long as there are enough correctly behaving servers the service as a whole behaves correctly; the meta data for BookKeeper is stored in ZooKeeper. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-16) Need to do path validation
[ https://issues.apache.org/jira/browse/ZOOKEEPER-16?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12668995#action_12668995 ] Mahadev konar commented on ZOOKEEPER-16: i think the we should avoid doing more work at the server and let the client handle the path checking. Doing this check in the PrepRequestPRocessor will have performance impact. On the other hand we could do some minor chekcing on the server to see if the path is null, starts with / and others... we can open up another jira for path validation on server side if you feel strongly abt it. for 2) their should be some client c libarary that should catch unicode characters .. again we can open another jira for that. for now we can go with this... Need to do path validation -- Key: ZOOKEEPER-16 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-16 Project: Zookeeper Issue Type: Bug Components: c client, java client, server Affects Versions: 3.0.0, 3.0.1 Reporter: Patrick Hunt Assignee: Patrick Hunt Fix For: 3.1.0 Attachments: ZOOKEEPER-16.patch, ZOOKEEPER-16.patch, ZOOKEEPER-16.patch Moved from SourceForge to Apache. http://sourceforge.net/tracker/index.php?func=detailaid=1963141group_id=209147atid=1008544 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-16) Need to do path validation
[ https://issues.apache.org/jira/browse/ZOOKEEPER-16?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12668997#action_12668997 ] Mahadev konar commented on ZOOKEEPER-16: well thinking abt it more ... - if we just do a check for path in create in prep requestprocessor then it should not be a performance impact Need to do path validation -- Key: ZOOKEEPER-16 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-16 Project: Zookeeper Issue Type: Bug Components: c client, java client, server Affects Versions: 3.0.0, 3.0.1 Reporter: Patrick Hunt Assignee: Patrick Hunt Fix For: 3.1.0 Attachments: ZOOKEEPER-16.patch, ZOOKEEPER-16.patch, ZOOKEEPER-16.patch Moved from SourceForge to Apache. http://sourceforge.net/tracker/index.php?func=detailaid=1963141group_id=209147atid=1008544 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-16) Need to do path validation
[ https://issues.apache.org/jira/browse/ZOOKEEPER-16?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mahadev konar updated ZOOKEEPER-16: --- Attachment: ZOOKEEPER-16.patch this patch adds the check at the server only on create. also added a test ot verify it, Need to do path validation -- Key: ZOOKEEPER-16 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-16 Project: Zookeeper Issue Type: Bug Components: c client, java client, server Affects Versions: 3.0.0, 3.0.1 Reporter: Patrick Hunt Assignee: Patrick Hunt Fix For: 3.1.0 Attachments: ZOOKEEPER-16.patch, ZOOKEEPER-16.patch, ZOOKEEPER-16.patch, ZOOKEEPER-16.patch, ZOOKEEPER-16.patch Moved from SourceForge to Apache. http://sourceforge.net/tracker/index.php?func=detailaid=1963141group_id=209147atid=1008544 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-16) Need to do path validation
[ https://issues.apache.org/jira/browse/ZOOKEEPER-16?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mahadev konar updated ZOOKEEPER-16: --- Status: Patch Available (was: Open) Need to do path validation -- Key: ZOOKEEPER-16 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-16 Project: Zookeeper Issue Type: Bug Components: c client, java client, server Affects Versions: 3.0.1, 3.0.0 Reporter: Patrick Hunt Assignee: Patrick Hunt Fix For: 3.1.0 Attachments: ZOOKEEPER-16.patch, ZOOKEEPER-16.patch, ZOOKEEPER-16.patch, ZOOKEEPER-16.patch, ZOOKEEPER-16.patch Moved from SourceForge to Apache. http://sourceforge.net/tracker/index.php?func=detailaid=1963141group_id=209147atid=1008544 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-16) Need to do path validation
[ https://issues.apache.org/jira/browse/ZOOKEEPER-16?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mahadev konar updated ZOOKEEPER-16: --- Hadoop Flags: [Reviewed] Need to do path validation -- Key: ZOOKEEPER-16 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-16 Project: Zookeeper Issue Type: Bug Components: c client, java client, server Affects Versions: 3.0.0, 3.0.1 Reporter: Patrick Hunt Assignee: Patrick Hunt Fix For: 3.1.0 Attachments: ZOOKEEPER-16.patch, ZOOKEEPER-16.patch, ZOOKEEPER-16.patch, ZOOKEEPER-16.patch, ZOOKEEPER-16.patch Moved from SourceForge to Apache. http://sourceforge.net/tracker/index.php?func=detailaid=1963141group_id=209147atid=1008544 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-285) the stat command does not return the correct mode
[ https://issues.apache.org/jira/browse/ZOOKEEPER-285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mahadev konar updated ZOOKEEPER-285: Affects Version/s: 3.0.0 3.0.1 Fix Version/s: 3.1.0 Assignee: Benjamin Reed the stat command does not return the correct mode - Key: ZOOKEEPER-285 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-285 Project: Zookeeper Issue Type: Bug Affects Versions: 3.0.0, 3.0.1 Reporter: Benjamin Reed Assignee: Benjamin Reed Fix For: 3.1.0 the stat command is always returning standalone it should return the actual mode it is in. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-286) Make GenerateLoad use InstanceContainers
[ https://issues.apache.org/jira/browse/ZOOKEEPER-286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mahadev konar updated ZOOKEEPER-286: Status: Open (was: Patch Available) cancelling patch to use svn mv for history on the files... Make GenerateLoad use InstanceContainers Key: ZOOKEEPER-286 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-286 Project: Zookeeper Issue Type: Improvement Affects Versions: 3.0.1, 3.0.0 Reporter: Benjamin Reed Assignee: Benjamin Reed Fix For: 3.1.0 Attachments: ZOOKEEPER-286.patch GenerateLoad is a pain to setup and run. It would be nice if it used the same infrastructure as the system test so that we can more easily run performance tests. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-286) Make GenerateLoad use InstanceContainers
[ https://issues.apache.org/jira/browse/ZOOKEEPER-286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mahadev konar updated ZOOKEEPER-286: Attachment: ZOOKEEPER-286.patch the prev patch did not apply cleanly. you need to run svn mv as ben last stated adn then apply the patch. Make GenerateLoad use InstanceContainers Key: ZOOKEEPER-286 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-286 Project: Zookeeper Issue Type: Improvement Affects Versions: 3.1.0 Reporter: Benjamin Reed Assignee: Benjamin Reed Fix For: 3.1.0 Attachments: ZOOKEEPER-286.patch, ZOOKEEPER-286.patch, ZOOKEEPER-286.patch, ZOOKEEPER-286.patch GenerateLoad is a pain to setup and run. It would be nice if it used the same infrastructure as the system test so that we can more easily run performance tests. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-286) Make GenerateLoad use InstanceContainers
[ https://issues.apache.org/jira/browse/ZOOKEEPER-286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mahadev konar updated ZOOKEEPER-286: Resolution: Fixed Hadoop Flags: [Reviewed] Status: Resolved (was: Patch Available) I just committed this. Thanks Ben. Make GenerateLoad use InstanceContainers Key: ZOOKEEPER-286 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-286 Project: Zookeeper Issue Type: Improvement Affects Versions: 3.1.0 Reporter: Benjamin Reed Assignee: Benjamin Reed Fix For: 3.1.0 Attachments: ZOOKEEPER-286.patch, ZOOKEEPER-286.patch, ZOOKEEPER-286.patch, ZOOKEEPER-286.patch GenerateLoad is a pain to setup and run. It would be nice if it used the same infrastructure as the system test so that we can more easily run performance tests. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (ZOOKEEPER-284) JMX doesn't get the clientPort correctly
[ https://issues.apache.org/jira/browse/ZOOKEEPER-284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mahadev konar resolved ZOOKEEPER-284. - Resolution: Fixed Hadoop Flags: [Reviewed] ZOOKEEPER-286 has been committed. So closing this one. JMX doesn't get the clientPort correctly Key: ZOOKEEPER-284 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-284 Project: Zookeeper Issue Type: Bug Affects Versions: 3.1.0 Reporter: Benjamin Reed Assignee: Patrick Hunt Priority: Minor Fix For: 3.1.0 The client port in JMX is always zero. it should be getting the client port from the cnxnfactory. it's a pretty easy fix. the really problem is that we have a setter for the clientPort as well, which is a bit more complicated to implement correctly. do we need a setter for the clientPort? i think we should make it a readonly attribute. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-289) add debug messages to nioserver select loop.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mahadev konar updated ZOOKEEPER-289: Resolution: Fixed Hadoop Flags: [Reviewed] Status: Resolved (was: Patch Available) I just committed this. add debug messages to nioserver select loop. Key: ZOOKEEPER-289 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-289 Project: Zookeeper Issue Type: Improvement Affects Versions: 3.0.0, 3.0.1 Reporter: Mahadev konar Assignee: Mahadev konar Fix For: 3.1.0 Attachments: ZOOKEEPER-289.patch, ZOOKEEPER-289.patch add some debug messages for any unexpected behaviour on select i/o in NIOServerCnxn. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-289) add debug messages to nioserver select loop.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mahadev konar updated ZOOKEEPER-289: Attachment: ZOOKEEPER-289.patch this patch add some debug messgaes. add debug messages to nioserver select loop. Key: ZOOKEEPER-289 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-289 Project: Zookeeper Issue Type: Improvement Reporter: Mahadev konar Assignee: Mahadev konar Attachments: ZOOKEEPER-289.patch add some debug messages for any unexpected behaviour on select i/o in NIOServerCnxn. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-289) add debug messages to nioserver select loop.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mahadev konar updated ZOOKEEPER-289: Fix Version/s: 3.1.0 Affects Version/s: 3.0.0 3.0.1 Status: Patch Available (was: Open) add debug messages to nioserver select loop. Key: ZOOKEEPER-289 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-289 Project: Zookeeper Issue Type: Improvement Affects Versions: 3.0.1, 3.0.0 Reporter: Mahadev konar Assignee: Mahadev konar Fix For: 3.1.0 Attachments: ZOOKEEPER-289.patch add some debug messages for any unexpected behaviour on select i/o in NIOServerCnxn. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (ZOOKEEPER-289) add debug messages to nioserver select loop.
add debug messages to nioserver select loop. Key: ZOOKEEPER-289 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-289 Project: Zookeeper Issue Type: Improvement Reporter: Mahadev konar Assignee: Mahadev konar Attachments: ZOOKEEPER-289.patch add some debug messages for any unexpected behaviour on select i/o in NIOServerCnxn. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-291) regression for legacy code using KeeperException.Code constants (due to 246)
[ https://issues.apache.org/jira/browse/ZOOKEEPER-291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mahadev konar updated ZOOKEEPER-291: Resolution: Fixed Hadoop Flags: [Reviewed] Status: Resolved (was: Patch Available) I just committed this. THnaks pat. regression for legacy code using KeeperException.Code constants (due to 246) Key: ZOOKEEPER-291 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-291 Project: Zookeeper Issue Type: Bug Components: java client Reporter: Patrick Hunt Assignee: Patrick Hunt Fix For: 3.1.0 Attachments: ZOOKEEPER-291.patch In 246 the old constants were deprecated and replace with enum. In the process usage of the orig constants was broken for switch statements, cases require compiletime constants. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-293) zoo_set needs to be abi compatible (3.1 changed the signature), fix this by adding zoo_set2
[ https://issues.apache.org/jira/browse/ZOOKEEPER-293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12670871#action_12670871 ] Mahadev konar commented on ZOOKEEPER-293: - +1 for the patch ... zoo_set needs to be abi compatible (3.1 changed the signature), fix this by adding zoo_set2 --- Key: ZOOKEEPER-293 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-293 Project: Zookeeper Issue Type: Bug Components: c client Affects Versions: 3.1.0 Reporter: Patrick Hunt Assignee: Patrick Hunt Priority: Critical Fix For: 3.1.0 Attachments: ZOOKEEPER-293.patch ZOOKEEPER-255 fixed an issue with zoo_set not providing access to stat structure, however this has broken b/w compatibility with previous releases. We need to: 1) revert zoo_set to not have stat parameter (keep b/w compat) 2) add zoo_set2 method with stat param added to the function signature 3) add a version.h file to src/c/include that provides zoo version detail to clients ie. #define ZOO_MAJOR_VERSION 3 #define ZOO_MINOR_VERSION 1 #define ZOO_PATCH_VERSION 0 (a new jira should be added to centralize version numbering, we now have the version number in 3 places in the source) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-293) zoo_set needs to be abi compatible (3.1 changed the signature), fix this by adding zoo_set2
[ https://issues.apache.org/jira/browse/ZOOKEEPER-293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mahadev konar updated ZOOKEEPER-293: Resolution: Fixed Hadoop Flags: [Reviewed] Status: Resolved (was: Patch Available) I just committed this. Thanks pat. zoo_set needs to be abi compatible (3.1 changed the signature), fix this by adding zoo_set2 --- Key: ZOOKEEPER-293 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-293 Project: Zookeeper Issue Type: Bug Components: c client Affects Versions: 3.1.0 Reporter: Patrick Hunt Assignee: Patrick Hunt Priority: Critical Fix For: 3.1.0 Attachments: ZOOKEEPER-293.patch ZOOKEEPER-255 fixed an issue with zoo_set not providing access to stat structure, however this has broken b/w compatibility with previous releases. We need to: 1) revert zoo_set to not have stat parameter (keep b/w compat) 2) add zoo_set2 method with stat param added to the function signature 3) add a version.h file to src/c/include that provides zoo version detail to clients ie. #define ZOO_MAJOR_VERSION 3 #define ZOO_MINOR_VERSION 1 #define ZOO_PATCH_VERSION 0 (a new jira should be added to centralize version numbering, we now have the version number in 3 places in the source) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (ZOOKEEPER-299) server startup scripts fail on a mac.
server startup scripts fail on a mac. - Key: ZOOKEEPER-299 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-299 Project: Zookeeper Issue Type: Bug Reporter: Mahadev konar Fix For: 3.2.0 JMX enabled by default readlink: illegal option -- f usage: readlink [-n] [file ...] ./zkEnv.sh no such file. if you run bin/zkServer.sh start this is the error i get. if I run it from the bin directory then it seems to be fine. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-302) Quote values in JMX ObjectNames
[ https://issues.apache.org/jira/browse/ZOOKEEPER-302?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12671281#action_12671281 ] Mahadev konar commented on ZOOKEEPER-302: - +1 for the patch passes the tests... Quote values in JMX ObjectNames Key: ZOOKEEPER-302 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-302 Project: Zookeeper Issue Type: Bug Affects Versions: 3.1.0 Reporter: Tom White Attachments: ZOOKEEPER-302.patch, zookeeper-302.patch Some characters are not allowed in ObjectName values and need quoting, see http://java.sun.com/javase/6/docs/api/javax/management/ObjectName.html. This came up with IPv6 addresses which contain a colon character. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-302) Quote values in JMX ObjectNames
[ https://issues.apache.org/jira/browse/ZOOKEEPER-302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mahadev konar updated ZOOKEEPER-302: Resolution: Fixed Hadoop Flags: [Reviewed] Status: Resolved (was: Patch Available) I just committed this. Thanks tom and pat. Quote values in JMX ObjectNames Key: ZOOKEEPER-302 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-302 Project: Zookeeper Issue Type: Bug Affects Versions: 3.1.0 Reporter: Tom White Assignee: Patrick Hunt Fix For: 3.1.0 Attachments: ZOOKEEPER-302.patch, zookeeper-302.patch Some characters are not allowed in ObjectName values and need quoting, see http://java.sun.com/javase/6/docs/api/javax/management/ObjectName.html. This came up with IPv6 addresses which contain a colon character. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-303) Bin scripts don't work on Mac
[
https://issues.apache.org/jira/browse/ZOOKEEPER-303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12671354#action_12671354
]
Mahadev konar commented on ZOOKEEPER-303:
-
+1 the patch looks good. .. ZOOKEEPER-299 is a duplicate of this ...
Bin scripts don't work on Mac
-
Key: ZOOKEEPER-303
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-303
Project: Zookeeper
Issue Type: Bug
Components: scripts
Environment: Mac OS X
Reporter: Tom White
Attachments: zookeeper-303.patch
Macs don't support the -f option in readlink
{noformat}
$ bin/zkServer.sh start
JMX enabled by default
readlink: illegal option -- f
usage: readlink [-n] [file ...]
{noformat}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (ZOOKEEPER-304) factor out common methods from zookeeper.java
factor out common methods from zookeeper.java - Key: ZOOKEEPER-304 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-304 Project: Zookeeper Issue Type: Improvement Affects Versions: 3.1.0 Reporter: Mahadev konar we need to factor out common methods from zookeeper.java to a commons directory for zookeeper so that it can be used both in client and server without each of them depending on each other. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (ZOOKEEPER-303) Bin scripts don't work on Mac
[
https://issues.apache.org/jira/browse/ZOOKEEPER-303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mahadev konar reassigned ZOOKEEPER-303:
---
Assignee: Tom White
Bin scripts don't work on Mac
-
Key: ZOOKEEPER-303
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-303
Project: Zookeeper
Issue Type: Bug
Components: scripts
Environment: Mac OS X
Reporter: Tom White
Assignee: Tom White
Attachments: zookeeper-303.patch
Macs don't support the -f option in readlink
{noformat}
$ bin/zkServer.sh start
JMX enabled by default
readlink: illegal option -- f
usage: readlink [-n] [file ...]
{noformat}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
