[jira] Commented: (ZOOKEEPER-421) zkpython run_tests.sh is missing #!
[ https://issues.apache.org/jira/browse/ZOOKEEPER-421?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12715538#action_12715538 ] Hudson commented on ZOOKEEPER-421: -- Integrated in ZooKeeper-trunk #333 (See [http://hudson.zones.apache.org/hudson/job/ZooKeeper-trunk/333/]) . zkpython run_tests.sh is missing #! > zkpython run_tests.sh is missing #! > --- > > Key: ZOOKEEPER-421 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-421 > Project: Zookeeper > Issue Type: Bug > Components: contrib-bindings >Reporter: Patrick Hunt >Assignee: Henry Robinson >Priority: Minor > Fix For: 3.2.0 > > Attachments: ZOOKEEPER-421.patch, ZOOKEEPER-421.patch > > > the scripts in the test directory of zkpython are missing #! headers > Probably: > #!/bin/sh > for shell scripts and > #!/usr/bin/python > for .py scripts? > Also include a shell script that will svn chmod the *.py scripts so that they > can be executed individually from the command line (shortcut > rather than (python foo.py). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (ZOOKEEPER-425) Add OSGi metadata to zookeeper.jar
Add OSGi metadata to zookeeper.jar -- Key: ZOOKEEPER-425 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-425 Project: Zookeeper Issue Type: Improvement Components: build Affects Versions: 3.1.1 Reporter: David Bosschaert After adding OSGi metadata to zookeeper.jar it can be used as both an OSGi bundle as well as an ordinary jar file. In the CXF/DOSGi project the buildsystem does this using the maven-bundle-plugin: http://svn.apache.org/repos/asf/cxf/dosgi/trunk/discovery/distributed/zookeeper-wrapper/pom.xml The MANIFEST.MF generated by maven-bundle-plugin is attached to this bug, this works for the CXF/DOSGi project. If your buildsystem isn't using maven, I would advise to use bnd (http://www.aqute.biz/Code/Bnd). BND defines its own ant task in which you should be able to use more or less the same instructions as were used in maven: ZooKeeper bundle This bundle contains the ZooKeeper library org.apache.hadoop.zookeeper 3.1.1 * *;version=3.1.1 Oh and one other thing. Is it really necessary to put the source code in the Jar file too? I would put that in a separate source distribution :) See also: http://mail-archives.apache.org/mod_mbox/hadoop-zookeeper-user/200905.mbox/%3c4a2009b1.3030...@yahoo-inc.com%3e -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-425) Add OSGi metadata to zookeeper.jar
[ https://issues.apache.org/jira/browse/ZOOKEEPER-425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Bosschaert updated ZOOKEEPER-425: --- Attachment: MANIFEST.MF The manifest generated by the CXF/DOSGi build system. > Add OSGi metadata to zookeeper.jar > -- > > Key: ZOOKEEPER-425 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-425 > Project: Zookeeper > Issue Type: Improvement > Components: build >Affects Versions: 3.1.1 >Reporter: David Bosschaert > Attachments: MANIFEST.MF > > > After adding OSGi metadata to zookeeper.jar it can be used as both an OSGi > bundle as well as an ordinary jar file. > In the CXF/DOSGi project the buildsystem does this using the > maven-bundle-plugin: > http://svn.apache.org/repos/asf/cxf/dosgi/trunk/discovery/distributed/zookeeper-wrapper/pom.xml > The MANIFEST.MF generated by maven-bundle-plugin is attached to this bug, > this works for the CXF/DOSGi project. > If your buildsystem isn't using maven, I would advise to use bnd > (http://www.aqute.biz/Code/Bnd). BND defines its own ant task in which you > should be able to use more or less the same instructions as were used in > maven: > > ZooKeeper bundle > This bundle contains the ZooKeeper > library > org.apache.hadoop.zookeeper > 3.1.1 > * > *;version=3.1.1 > > Oh and one other thing. Is it really necessary to put the source code in the > Jar file too? I would put that in a separate source distribution :) > See also: > http://mail-archives.apache.org/mod_mbox/hadoop-zookeeper-user/200905.mbox/%3c4a2009b1.3030...@yahoo-inc.com%3e -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-426) Windows versions of zookeeper scrips
[ https://issues.apache.org/jira/browse/ZOOKEEPER-426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Bosschaert updated ZOOKEEPER-426: --- Attachment: zkServer.cmd zkEnv.cmd zkCli.cmd > Windows versions of zookeeper scrips > > > Key: ZOOKEEPER-426 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-426 > Project: Zookeeper > Issue Type: Improvement > Components: scripts >Affects Versions: 3.1.1 >Reporter: David Bosschaert > Attachments: zkCli.cmd, zkEnv.cmd, zkServer.cmd > > > Attached are a some Windows versions of the zookeeper scripts. They aren't as > powerful as the .sh ones but they do work for me and can be invoked with any > directory as the current dir. > The biggest trick in the scripts is in the zkEnv.cmd one where it says: > set ZOOCFGDIR=%~dp0%..\conf > this basically figures out the location of the zkEnv.cmd file and sets the > conf directory relative to that. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (ZOOKEEPER-426) Windows versions of zookeeper scrips
Windows versions of zookeeper scrips Key: ZOOKEEPER-426 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-426 Project: Zookeeper Issue Type: Improvement Components: scripts Affects Versions: 3.1.1 Reporter: David Bosschaert Attachments: zkCli.cmd, zkEnv.cmd, zkServer.cmd Attached are a some Windows versions of the zookeeper scripts. They aren't as powerful as the .sh ones but they do work for me and can be invoked with any directory as the current dir. The biggest trick in the scripts is in the zkEnv.cmd one where it says: set ZOOCFGDIR=%~dp0%..\conf this basically figures out the location of the zkEnv.cmd file and sets the conf directory relative to that. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-426) Windows versions of zookeeper scripts
[ https://issues.apache.org/jira/browse/ZOOKEEPER-426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Bosschaert updated ZOOKEEPER-426: --- Summary: Windows versions of zookeeper scripts (was: Windows versions of zookeeper scrips) > Windows versions of zookeeper scripts > - > > Key: ZOOKEEPER-426 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-426 > Project: Zookeeper > Issue Type: Improvement > Components: scripts >Affects Versions: 3.1.1 >Reporter: David Bosschaert > Attachments: zkCli.cmd, zkEnv.cmd, zkServer.cmd > > > Attached are a some Windows versions of the zookeeper scripts. They aren't as > powerful as the .sh ones but they do work for me and can be invoked with any > directory as the current dir. > The biggest trick in the scripts is in the zkEnv.cmd one where it says: > set ZOOCFGDIR=%~dp0%..\conf > this basically figures out the location of the zkEnv.cmd file and sets the > conf directory relative to that. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-315) add forrest docs for bookkeeper.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Flavio Paiva Junqueira updated ZOOKEEPER-315: - Attachment: ZOOKEEPER-315.patch > add forrest docs for bookkeeper. > > > Key: ZOOKEEPER-315 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-315 > Project: Zookeeper > Issue Type: Improvement > Components: contrib-bookkeeper >Affects Versions: 3.1.0 >Reporter: Mahadev konar >Assignee: Flavio Paiva Junqueira >Priority: Blocker > Fix For: 3.2.0 > > Attachments: ZOOKEEPER-315.patch, ZOOKEEPER-315.patch > > > we should have forrest docs for bookkeeper for > - how to install bookkeeper > - usage model > - programming examples for users > - FAQ -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-408) address all findbugs warnings in persistence classes
[ https://issues.apache.org/jira/browse/ZOOKEEPER-408?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Flavio Paiva Junqueira updated ZOOKEEPER-408: - Attachment: ZOOKEEPER-408.patch I have excluded the bug warning of AuthFastLeaderElection. In my opinion, the way it is implement is good. > address all findbugs warnings in persistence classes > > > Key: ZOOKEEPER-408 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-408 > Project: Zookeeper > Issue Type: Sub-task >Reporter: Patrick Hunt >Assignee: Mahadev konar > Fix For: 3.2.0 > > Attachments: ZOOKEEPER-408.patch, ZOOKEEPER-408.patch, > ZOOKEEPER-408.patch > > > trunk/src/java/main/org/apache/zookeeper/server/DataTree.java > trunk/src/java/main/org/apache/zookeeper/server/persistence/FileTxnSnapLog.java > trunk/src/java/main/org/apache/zookeeper/server/persistence/FileTxnLog.java > trunk/src/java/main/org/apache/zookeeper/server/persistence/Util.java > trunk/src/java/main/org/apache/zookeeper/server/DataNode.java > trunk/src/java/main/org/apache/zookeeper/server/upgrade/DataNodeV1.java > trunk/src/java/main/org/apache/zookeeper/server/upgrade/DataTreeV1.java -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-408) address all findbugs warnings in persistence classes
[ https://issues.apache.org/jira/browse/ZOOKEEPER-408?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mahadev konar updated ZOOKEEPER-408: Status: Patch Available (was: Open) > address all findbugs warnings in persistence classes > > > Key: ZOOKEEPER-408 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-408 > Project: Zookeeper > Issue Type: Sub-task >Reporter: Patrick Hunt >Assignee: Mahadev konar > Fix For: 3.2.0 > > Attachments: ZOOKEEPER-408.patch, ZOOKEEPER-408.patch, > ZOOKEEPER-408.patch > > > trunk/src/java/main/org/apache/zookeeper/server/DataTree.java > trunk/src/java/main/org/apache/zookeeper/server/persistence/FileTxnSnapLog.java > trunk/src/java/main/org/apache/zookeeper/server/persistence/FileTxnLog.java > trunk/src/java/main/org/apache/zookeeper/server/persistence/Util.java > trunk/src/java/main/org/apache/zookeeper/server/DataNode.java > trunk/src/java/main/org/apache/zookeeper/server/upgrade/DataNodeV1.java > trunk/src/java/main/org/apache/zookeeper/server/upgrade/DataTreeV1.java -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-290) Bad Address on Bookie
[
https://issues.apache.org/jira/browse/ZOOKEEPER-290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mahadev konar updated ZOOKEEPER-290:
Fix Version/s: (was: 3.2.0)
3.3.0
moving to 3.3 since we havent been able to reproduce this.
> Bad Address on Bookie
> -
>
> Key: ZOOKEEPER-290
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-290
> Project: Zookeeper
> Issue Type: Bug
> Components: contrib-bookkeeper
>Reporter: Flavio Paiva Junqueira
> Fix For: 3.3.0
>
>
> I'm getting this exception sometimes when running a bookie under a high
> volume of requests:
> {noformat}
> java.io.IOException: Bad address
> at sun.nio.ch.FileDispatcher.writev0(Native Method)
> at sun.nio.ch.FileDispatcher.writev(FileDispatcher.java:51)
> at sun.nio.ch.IOUtil.write(IOUtil.java:164)
> at sun.nio.ch.FileChannelImpl.write0(FileChannelImpl.java:232)
> at sun.nio.ch.FileChannelImpl.write(FileChannelImpl.java:249)
> at java.nio.channels.FileChannel.write(FileChannel.java:222)
> at org.apache.bookkeeper.bookie.Bookie.run(Bookie.java:246)
> {noformat}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (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
]
Benjamin Reed reassigned ZOOKEEPER-196:
---
Assignee: Benjamin Reed
> 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
>Assignee: Benjamin Reed
> 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] 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
]
Benjamin Reed updated ZOOKEEPER-196:
Attachment: ZOOKEEPER-196.patch
fixed this problem and another problem that stated that watches get removed on
disconnect.
> 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
>Assignee: Benjamin Reed
> Fix For: 3.2.0
>
> Attachments: ZOOKEEPER-196.patch
>
>
> 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] 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
]
Benjamin Reed updated ZOOKEEPER-196:
Status: Patch Available (was: Open)
> 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
>Assignee: Benjamin Reed
> Fix For: 3.2.0
>
> Attachments: ZOOKEEPER-196.patch
>
>
> 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] Updated: (ZOOKEEPER-358) Throw exception when ledger does not exist
[ https://issues.apache.org/jira/browse/ZOOKEEPER-358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Reed updated ZOOKEEPER-358: Hadoop Flags: [Reviewed] +1 looks good > Throw exception when ledger does not exist > -- > > Key: ZOOKEEPER-358 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-358 > Project: Zookeeper > Issue Type: Improvement > Components: contrib-bookkeeper >Affects Versions: 3.1.1 >Reporter: Luca Telloli >Assignee: Flavio Paiva Junqueira >Priority: Minor > Fix For: 3.2.0 > > Attachments: ZOOKEEPER-358.patch, ZOOKEEPER-358.patch > > > Currently, openLedger() in the BookKeeper client returns null if the ledger > ID does not exist on ZK. Maybe it would be better to throw a specific > exception so it can be handled by the client side. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-356) Masking bookie failure during writes to a ledger
[ https://issues.apache.org/jira/browse/ZOOKEEPER-356?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Flavio Paiva Junqueira updated ZOOKEEPER-356: - Fix Version/s: 3.2.0 > Masking bookie failure during writes to a ledger > > > Key: ZOOKEEPER-356 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-356 > Project: Zookeeper > Issue Type: New Feature > Components: contrib-bookkeeper >Reporter: Flavio Paiva Junqueira >Assignee: Flavio Paiva Junqueira > Fix For: 3.2.0 > > Attachments: ZOOKEEPER-BOOKKEEPER-356.patch > > > The idea of this jira is to work out the changes necessary to make a client > mask the failure of a bookie while writing to a ledger. I'm submitting a > preliminary patch, but before I submit a final one, I need to have 288 > committed. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (ZOOKEEPER-427) ZooKeeper server unexpectedly high CPU utilisation
ZooKeeper server unexpectedly high CPU utilisation -- Key: ZOOKEEPER-427 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-427 Project: Zookeeper Issue Type: Bug Affects Versions: 3.1.1 Environment: Linux: 2.6.18-92.1.18.el5 #1 SMP Wed Nov 12 09:19:49 EST 2008 x86_64 x86_64 x86_64 GNU/Linux java version "1.6.0_03" Java(TM) SE Runtime Environment (build 1.6.0_03-b05) Java HotSpot(TM) 64-Bit Server VM (build 1.6.0_03-b05, mixed mode) Reporter: Satish Bhatti I am running a 5 node ZooKeeper cluster and I noticed that one of them has very high CPU usage: PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND 6883 infact 22 0 725m 41m 4188 S 95 0.5 5671:54 java It is not "doing anything" application-wise at this point, so I was wondering why the heck it's using up so much CPU. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-427) ZooKeeper server unexpectedly high CPU utilisation
[ https://issues.apache.org/jira/browse/ZOOKEEPER-427?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Satish Bhatti updated ZOOKEEPER-427: Attachment: zookeeper.log zookeeper-jstack.log Attached a jstack and the zookeeper logfile. > ZooKeeper server unexpectedly high CPU utilisation > -- > > Key: ZOOKEEPER-427 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-427 > Project: Zookeeper > Issue Type: Bug >Affects Versions: 3.1.1 > Environment: Linux: 2.6.18-92.1.18.el5 #1 SMP Wed Nov 12 09:19:49 EST > 2008 x86_64 x86_64 x86_64 GNU/Linux > java version "1.6.0_03" > Java(TM) SE Runtime Environment (build 1.6.0_03-b05) > Java HotSpot(TM) 64-Bit Server VM (build 1.6.0_03-b05, mixed mode) >Reporter: Satish Bhatti > Attachments: zookeeper-jstack.log, zookeeper.log > > > I am running a 5 node ZooKeeper cluster and I noticed that one of them has > very high CPU usage: > PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND > 6883 infact 22 0 725m 41m 4188 S 95 0.5 > 5671:54 java > It is not "doing anything" application-wise at this point, so I was wondering > why the heck it's using up so much CPU. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-336) single bad client can cause server to stop accepting connections
[ https://issues.apache.org/jira/browse/ZOOKEEPER-336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Flavio Paiva Junqueira updated ZOOKEEPER-336: - Status: Open (was: Patch Available) > single bad client can cause server to stop accepting connections > > > Key: ZOOKEEPER-336 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-336 > Project: Zookeeper > Issue Type: Improvement > Components: c client, java client, server >Reporter: Patrick Hunt >Assignee: Henry Robinson >Priority: Critical > Fix For: 3.2.0 > > Attachments: ZOOKEEPER-336.patch, ZOOKEEPER-336.patch, > ZOOKEEPER-336.patch, ZOOKEEPER-336.patch > > > One user saw a case where a single mis-programmed client was overloading the > server with connections - the client was creating a huge number of sessions > to the server. This caused all of the fds on the server to become used. > Seems like we should have some way of limiting (configurable override) the > maximum number of sessions from a single client (say 10 by default?) Also we > should output warnings when this limit is exceeded (or attempt to exceed). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-336) single bad client can cause server to stop accepting connections
[ https://issues.apache.org/jira/browse/ZOOKEEPER-336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12715690#action_12715690 ] Flavio Paiva Junqueira commented on ZOOKEEPER-336: -- Henry, I agree with Patrick that it would be good to have a C test as well. Could you please add one to this patch? > single bad client can cause server to stop accepting connections > > > Key: ZOOKEEPER-336 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-336 > Project: Zookeeper > Issue Type: Improvement > Components: c client, java client, server >Reporter: Patrick Hunt >Assignee: Henry Robinson >Priority: Critical > Fix For: 3.2.0 > > Attachments: ZOOKEEPER-336.patch, ZOOKEEPER-336.patch, > ZOOKEEPER-336.patch, ZOOKEEPER-336.patch > > > One user saw a case where a single mis-programmed client was overloading the > server with connections - the client was creating a huge number of sessions > to the server. This caused all of the fds on the server to become used. > Seems like we should have some way of limiting (configurable override) the > maximum number of sessions from a single client (say 10 by default?) Also we > should output warnings when this limit is exceeded (or attempt to exceed). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-358) Throw exception when ledger does not exist
[ https://issues.apache.org/jira/browse/ZOOKEEPER-358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Reed updated ZOOKEEPER-358: Resolution: Fixed Status: Resolved (was: Patch Available) Committed revision 781173. > Throw exception when ledger does not exist > -- > > Key: ZOOKEEPER-358 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-358 > Project: Zookeeper > Issue Type: Improvement > Components: contrib-bookkeeper >Affects Versions: 3.1.1 >Reporter: Luca Telloli >Assignee: Flavio Paiva Junqueira >Priority: Minor > Fix For: 3.2.0 > > Attachments: ZOOKEEPER-358.patch, ZOOKEEPER-358.patch > > > Currently, openLedger() in the BookKeeper client returns null if the ledger > ID does not exist on ZK. Maybe it would be better to throw a specific > exception so it can be handled by the client side. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-427) ZooKeeper server unexpectedly high CPU utilisation
[ https://issues.apache.org/jira/browse/ZOOKEEPER-427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12715693#action_12715693 ] Mahadev konar commented on ZOOKEEPER-427: - satish, can you just try strace to see which one of thread is spinning? also, with the log files it seems like you are doing a lot of trasactions through some other zookeeper server? > ZooKeeper server unexpectedly high CPU utilisation > -- > > Key: ZOOKEEPER-427 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-427 > Project: Zookeeper > Issue Type: Bug >Affects Versions: 3.1.1 > Environment: Linux: 2.6.18-92.1.18.el5 #1 SMP Wed Nov 12 09:19:49 EST > 2008 x86_64 x86_64 x86_64 GNU/Linux > java version "1.6.0_03" > Java(TM) SE Runtime Environment (build 1.6.0_03-b05) > Java HotSpot(TM) 64-Bit Server VM (build 1.6.0_03-b05, mixed mode) >Reporter: Satish Bhatti > Attachments: zookeeper-jstack.log, zookeeper.log > > > I am running a 5 node ZooKeeper cluster and I noticed that one of them has > very high CPU usage: > PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND > 6883 infact 22 0 725m 41m 4188 S 95 0.5 > 5671:54 java > It is not "doing anything" application-wise at this point, so I was wondering > why the heck it's using up so much CPU. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (ZOOKEEPER-428) logging should be makred as warn rathen than error in NIOServerCnxn.
logging should be makred as warn rathen than error in NIOServerCnxn. Key: ZOOKEEPER-428 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-428 Project: Zookeeper Issue Type: Improvement Reporter: Mahadev konar Errors such as these should be marked as warn and not error. 7:54,094 ERROR [NIOServerCxn.Factory:21810] server.NIOServerCnxn(543): Client has seen zxid 0x10 our last zxid is 0x4 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-428) logging should be makred as warn rathen than error in NIOServerCnxn.
[ https://issues.apache.org/jira/browse/ZOOKEEPER-428?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mahadev konar updated ZOOKEEPER-428: Fix Version/s: 3.2.0 Assignee: Patrick Hunt > logging should be makred as warn rathen than error in NIOServerCnxn. > > > Key: ZOOKEEPER-428 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-428 > Project: Zookeeper > Issue Type: Improvement >Reporter: Mahadev konar >Assignee: Patrick Hunt > Fix For: 3.2.0 > > > Errors such as these should be marked as warn and not error. > 7:54,094 ERROR [NIOServerCxn.Factory:21810] > server.NIOServerCnxn(543): Client has seen zxid 0x10 our last zxid is 0x4 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-408) address all findbugs warnings in persistence classes
[ https://issues.apache.org/jira/browse/ZOOKEEPER-408?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Reed updated ZOOKEEPER-408: Hadoop Flags: [Reviewed] +1 good job > address all findbugs warnings in persistence classes > > > Key: ZOOKEEPER-408 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-408 > Project: Zookeeper > Issue Type: Sub-task >Reporter: Patrick Hunt >Assignee: Mahadev konar > Fix For: 3.2.0 > > Attachments: ZOOKEEPER-408.patch, ZOOKEEPER-408.patch, > ZOOKEEPER-408.patch > > > trunk/src/java/main/org/apache/zookeeper/server/DataTree.java > trunk/src/java/main/org/apache/zookeeper/server/persistence/FileTxnSnapLog.java > trunk/src/java/main/org/apache/zookeeper/server/persistence/FileTxnLog.java > trunk/src/java/main/org/apache/zookeeper/server/persistence/Util.java > trunk/src/java/main/org/apache/zookeeper/server/DataNode.java > trunk/src/java/main/org/apache/zookeeper/server/upgrade/DataNodeV1.java > trunk/src/java/main/org/apache/zookeeper/server/upgrade/DataTreeV1.java -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-427) ZooKeeper server unexpectedly high CPU utilisation
[ https://issues.apache.org/jira/browse/ZOOKEEPER-427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12715698#action_12715698 ] Satish Bhatti commented on ZOOKEEPER-427: - I ran: strace -o zookeeper-strace.log -p6883 So far nothing in the logfile. less zookeeper-strace.log futex(0x404079d0, FUTEX_WAIT, 6884, NULL > ZooKeeper server unexpectedly high CPU utilisation > -- > > Key: ZOOKEEPER-427 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-427 > Project: Zookeeper > Issue Type: Bug >Affects Versions: 3.1.1 > Environment: Linux: 2.6.18-92.1.18.el5 #1 SMP Wed Nov 12 09:19:49 EST > 2008 x86_64 x86_64 x86_64 GNU/Linux > java version "1.6.0_03" > Java(TM) SE Runtime Environment (build 1.6.0_03-b05) > Java HotSpot(TM) 64-Bit Server VM (build 1.6.0_03-b05, mixed mode) >Reporter: Satish Bhatti > Attachments: zookeeper-jstack.log, zookeeper.log > > > I am running a 5 node ZooKeeper cluster and I noticed that one of them has > very high CPU usage: > PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND > 6883 infact 22 0 725m 41m 4188 S 95 0.5 > 5671:54 java > It is not "doing anything" application-wise at this point, so I was wondering > why the heck it's using up so much CPU. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-427) ZooKeeper server unexpectedly high CPU utilisation
[ https://issues.apache.org/jira/browse/ZOOKEEPER-427?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Satish Bhatti updated ZOOKEEPER-427: Attachment: zoo.cfg Attached zoo.cfg file. > ZooKeeper server unexpectedly high CPU utilisation > -- > > Key: ZOOKEEPER-427 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-427 > Project: Zookeeper > Issue Type: Bug >Affects Versions: 3.1.1 > Environment: Linux: 2.6.18-92.1.18.el5 #1 SMP Wed Nov 12 09:19:49 EST > 2008 x86_64 x86_64 x86_64 GNU/Linux > java version "1.6.0_03" > Java(TM) SE Runtime Environment (build 1.6.0_03-b05) > Java HotSpot(TM) 64-Bit Server VM (build 1.6.0_03-b05, mixed mode) >Reporter: Satish Bhatti > Attachments: zoo.cfg, zookeeper-jstack.log, zookeeper.log > > > I am running a 5 node ZooKeeper cluster and I noticed that one of them has > very high CPU usage: > PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND > 6883 infact 22 0 725m 41m 4188 S 95 0.5 > 5671:54 java > It is not "doing anything" application-wise at this point, so I was wondering > why the heck it's using up so much CPU. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-427) ZooKeeper server unexpectedly high CPU utilisation
[ https://issues.apache.org/jira/browse/ZOOKEEPER-427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12715714#action_12715714 ] Mahadev konar commented on ZOOKEEPER-427: - satish for strace you will have to do an strace on all the pid's in /proc/6883/tasks/ to see which of the threads is spinning and on what... > ZooKeeper server unexpectedly high CPU utilisation > -- > > Key: ZOOKEEPER-427 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-427 > Project: Zookeeper > Issue Type: Bug >Affects Versions: 3.1.1 > Environment: Linux: 2.6.18-92.1.18.el5 #1 SMP Wed Nov 12 09:19:49 EST > 2008 x86_64 x86_64 x86_64 GNU/Linux > java version "1.6.0_03" > Java(TM) SE Runtime Environment (build 1.6.0_03-b05) > Java HotSpot(TM) 64-Bit Server VM (build 1.6.0_03-b05, mixed mode) >Reporter: Satish Bhatti > Attachments: zoo.cfg, zookeeper-jstack.log, zookeeper.log > > > I am running a 5 node ZooKeeper cluster and I noticed that one of them has > very high CPU usage: > PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND > 6883 infact 22 0 725m 41m 4188 S 95 0.5 > 5671:54 java > It is not "doing anything" application-wise at this point, so I was wondering > why the heck it's using up so much CPU. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-427) ZooKeeper server unexpectedly high CPU utilisation
[ https://issues.apache.org/jira/browse/ZOOKEEPER-427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12715723#action_12715723 ] Satish Bhatti commented on ZOOKEEPER-427: - oops! Sorry, Mahadev, I already bounced that zookeeper server, (it's a production server, so I didn't want to leave it flapping for too long) and it's been behaving well since. If I can reproduce the problem I will run strace as you have suggested. > ZooKeeper server unexpectedly high CPU utilisation > -- > > Key: ZOOKEEPER-427 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-427 > Project: Zookeeper > Issue Type: Bug >Affects Versions: 3.1.1 > Environment: Linux: 2.6.18-92.1.18.el5 #1 SMP Wed Nov 12 09:19:49 EST > 2008 x86_64 x86_64 x86_64 GNU/Linux > java version "1.6.0_03" > Java(TM) SE Runtime Environment (build 1.6.0_03-b05) > Java HotSpot(TM) 64-Bit Server VM (build 1.6.0_03-b05, mixed mode) >Reporter: Satish Bhatti > Attachments: zoo.cfg, zookeeper-jstack.log, zookeeper.log > > > I am running a 5 node ZooKeeper cluster and I noticed that one of them has > very high CPU usage: > PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND > 6883 infact 22 0 725m 41m 4188 S 95 0.5 > 5671:54 java > It is not "doing anything" application-wise at this point, so I was wondering > why the heck it's using up so much CPU. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-427) ZooKeeper server unexpectedly high CPU utilisation
[ https://issues.apache.org/jira/browse/ZOOKEEPER-427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12715731#action_12715731 ] Mahadev konar commented on ZOOKEEPER-427: - no worries satish, I hope we could have gotten that trace though... We had seen similar behavior in another jira ZOOKEEPER-287, and wanted to make sure if both are caused by similar problems. I have linked these two together. Do update the jira in case you run into this again. > ZooKeeper server unexpectedly high CPU utilisation > -- > > Key: ZOOKEEPER-427 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-427 > Project: Zookeeper > Issue Type: Bug >Affects Versions: 3.1.1 > Environment: Linux: 2.6.18-92.1.18.el5 #1 SMP Wed Nov 12 09:19:49 EST > 2008 x86_64 x86_64 x86_64 GNU/Linux > java version "1.6.0_03" > Java(TM) SE Runtime Environment (build 1.6.0_03-b05) > Java HotSpot(TM) 64-Bit Server VM (build 1.6.0_03-b05, mixed mode) >Reporter: Satish Bhatti > Attachments: zoo.cfg, zookeeper-jstack.log, zookeeper.log > > > I am running a 5 node ZooKeeper cluster and I noticed that one of them has > very high CPU usage: > PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND > 6883 infact 22 0 725m 41m 4188 S 95 0.5 > 5671:54 java > It is not "doing anything" application-wise at this point, so I was wondering > why the heck it's using up so much CPU. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Build failed in Hudson: Zookeeper-Patch-vesta.apache.org #99
See http://hudson.zones.apache.org/hudson/job/Zookeeper-Patch-vesta.apache.org/99/changes Changes: [breed] ZOOKEEPER-358. Throw exception when ledger does not exist [phunt] ZOOKEEPER-421. zkpython run_tests.sh is missing #! -- [...truncated 264 lines...] [exec] [exec] [exec] /home/hudson/tools/ant/latest/bin/ant -Dfindbugs.home=/home/nigel/tools/findbugs/latest -Djava5.home=/home/hudson/tools/java/latest1.5 -Dforrest.home=/home/nigel/tools/forrest/latest -DZooKeeperPatchProcess= findbugs [exec] Buildfile: build.xml [exec] [exec] check-for-findbugs: [exec] [exec] clover.setup: [exec] [exec] clover.info: [exec] [exec] clover: [exec] [exec] init: [exec] [exec] jute: [exec] [exec] compile_jute_uptodate: [exec] [exec] compile_jute: [exec] [exec] ver-gen: [exec] [exec] svn-revision: [exec] [exec] version-info: [exec] [exec] build-generated: [exec] [javac] Compiling 1 source file to http://hudson.zones.apache.org/hudson/job/Zookeeper-Patch-vesta.apache.org/ws/trunk/build/classes [exec] [exec] compile-main: [exec] [copy] Copying 1 file to http://hudson.zones.apache.org/hudson/job/Zookeeper-Patch-vesta.apache.org/ws/trunk/build/classes [exec] [exec] compile-extra: [exec] [exec] compile: [exec] [exec] jar: [exec] [jar] Building jar: http://hudson.zones.apache.org/hudson/job/Zookeeper-Patch-vesta.apache.org/ws/trunk/zookeeper-dev.jar [exec] [exec] findbugs: [exec] [mkdir] Created dir: http://hudson.zones.apache.org/hudson/job/Zookeeper-Patch-vesta.apache.org/ws/trunk/build/test/findbugs [exec] [findbugs] Executing findbugs from ant task [exec] [findbugs] Running FindBugs... [exec] [findbugs] The following classes needed for analysis were missing: [exec] [findbugs] jline.Completor [exec] [findbugs] Warnings generated: 1 [exec] [findbugs] Missing classes: 2 [exec] [findbugs] Calculating exit code... [exec] [findbugs] Setting 'missing class' flag (2) [exec] [findbugs] Setting 'bugs found' flag (1) [exec] [findbugs] Exit code set to: 3 [exec] [findbugs] Java Result: 3 [exec] [findbugs] Classes needed for analysis were missing [exec] [findbugs] Output saved to http://hudson.zones.apache.org/hudson/job/Zookeeper-Patch-vesta.apache.org/ws/trunk/build/test/findbugs/zookeeper-findbugs-report.xml [exec] [xslt] Processing http://hudson.zones.apache.org/hudson/job/Zookeeper-Patch-vesta.apache.org/ws/trunk/build/test/findbugs/zookeeper-findbugs-report.xml to http://hudson.zones.apache.org/hudson/job/Zookeeper-Patch-vesta.apache.org/ws/trunk/build/test/findbugs/zookeeper-findbugs-report.html [exec] [xslt] Loading stylesheet /home/nigel/tools/findbugs/latest/src/xsl/default.xsl [exec] [exec] BUILD SUCCESSFUL [exec] Total time: 29 seconds [exec] Starting with http://hudson.zones.apache.org/hudson/job/Zookeeper-Patch-vesta.apache.org/ws/patchprocess/trunkFindbugsWarnings.xml [exec] Merging http://hudson.zones.apache.org/hudson/job/Zookeeper-Patch-vesta.apache.org/ws/patchprocess/patchFindbugsWarnings.xml [exec] [exec] [exec] == [exec] == [exec] Determining number of patched release audit warnings. [exec] == [exec] == [exec] [exec] [exec] /home/hudson/tools/ant/latest/bin/ant -Djava5.home=/home/hudson/tools/java/latest1.5 -Dforrest.home=/home/nigel/tools/forrest/latest -DZooKeeperPatchProcess= releaseaudit > http://hudson.zones.apache.org/hudson/job/Zookeeper-Patch-vesta.apache.org/ws/patchprocess/patchReleaseAuditWarnings.txt 2>&1 [exec] [exec] [exec] There appear to be 171 release audit warnings before the patch and 0 release audit warnings after applying the patch. [exec] [exec] [exec] == [exec] == [exec] Running core tests. [exec] == [exec] == [exec] [exec] [exec] Warning: bad ps syntax, perhaps a bogus '-'? See http://procps.sf.net/faq.html [exec] /bin/kill -9 14091 [exec] kill: No such process [exec] /home/hudson/tools/ant/latest/bin/ant -DZooKeeperPatchProcess= -Dtest.junit.output.forma
[jira] Commented: (ZOOKEEPER-408) address all findbugs warnings in persistence classes
[ https://issues.apache.org/jira/browse/ZOOKEEPER-408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12715735#action_12715735 ] Hadoop QA commented on ZOOKEEPER-408: - -1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12409680/ZOOKEEPER-408.patch against trunk revision 781173. +1 @author. The patch does not contain any @author tags. +1 tests included. The patch appears to include 27 new or modified tests. +1 javadoc. The javadoc tool did not generate any warning messages. +1 javac. The applied patch does not increase the total number of javac compiler warnings. +1 findbugs. The patch does not introduce any new Findbugs warnings. +1 release audit. The applied patch does not increase the total number of release audit warnings. -1 core tests. The patch failed core unit tests. +1 contrib tests. The patch passed contrib unit tests. Test results: http://hudson.zones.apache.org/hudson/job/Zookeeper-Patch-vesta.apache.org/99/testReport/ Findbugs warnings: http://hudson.zones.apache.org/hudson/job/Zookeeper-Patch-vesta.apache.org/99/artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html Console output: http://hudson.zones.apache.org/hudson/job/Zookeeper-Patch-vesta.apache.org/99/console This message is automatically generated. > address all findbugs warnings in persistence classes > > > Key: ZOOKEEPER-408 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-408 > Project: Zookeeper > Issue Type: Sub-task >Reporter: Patrick Hunt >Assignee: Mahadev konar > Fix For: 3.2.0 > > Attachments: ZOOKEEPER-408.patch, ZOOKEEPER-408.patch, > ZOOKEEPER-408.patch > > > trunk/src/java/main/org/apache/zookeeper/server/DataTree.java > trunk/src/java/main/org/apache/zookeeper/server/persistence/FileTxnSnapLog.java > trunk/src/java/main/org/apache/zookeeper/server/persistence/FileTxnLog.java > trunk/src/java/main/org/apache/zookeeper/server/persistence/Util.java > trunk/src/java/main/org/apache/zookeeper/server/DataNode.java > trunk/src/java/main/org/apache/zookeeper/server/upgrade/DataNodeV1.java > trunk/src/java/main/org/apache/zookeeper/server/upgrade/DataTreeV1.java -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Build failed in Hudson: Zookeeper-Patch-vesta.apache.org #100
See http://hudson.zones.apache.org/hudson/job/Zookeeper-Patch-vesta.apache.org/100/ -- [...truncated 120775 lines...] [exec] [exec] libtool: compile: gcc -DHAVE_CONFIG_H -I. -Ihttp://hudson.zones.apache.org/hudson/job/Zookeeper-Patch-vesta.apache.org/ws/trunk/src/c -Ihttp://hudson.zones.apache.org/hudson/job/Zookeeper-Patch-vesta.apache.org/ws/trunk/src/c/include -Ihttp://hudson.zones.apache.org/hudson/job/Zookeeper-Patch-vesta.apache.org/ws/trunk/src/c/tests -Ihttp://hudson.zones.apache.org/hudson/job/Zookeeper-Patch-vesta.apache.org/ws/trunk/src/c/generated -DTHREADED -g -O2 -MT libzkmt_la-mt_adaptor.lo -MD -MP -MF .deps/libzkmt_la-mt_adaptor.Tpo -c http://hudson.zones.apache.org/hudson/job/Zookeeper-Patch-vesta.apache.org/ws/trunk/src/c/src/mt_adaptor.c -o libzkmt_la-mt_adaptor.o >/dev/null 2>&1 [exec] [exec] mv -f .deps/libzkmt_la-mt_adaptor.Tpo .deps/libzkmt_la-mt_adaptor.Plo [exec] [exec] /bin/bash ./libtool --tag=CC --mode=link gcc -DTHREADED -g -O2 -o libzkmt.la libzkmt_la-zookeeper.lo libzkmt_la-recordio.lo libzkmt_la-zookeeper.jute.lo libzkmt_la-zk_log.lo libzkmt_la-zk_hashtable.lo libzkmt_la-mt_adaptor.lo -lm [exec] [exec] libtool: link: ar cru .libs/libzkmt.a .libs/libzkmt_la-zookeeper.o .libs/libzkmt_la-recordio.o .libs/libzkmt_la-zookeeper.jute.o .libs/libzkmt_la-zk_log.o .libs/libzkmt_la-zk_hashtable.o .libs/libzkmt_la-mt_adaptor.o [exec] [exec] libtool: link: ranlib .libs/libzkmt.a [exec] [exec] libtool: link: ( cd ".libs" && rm -f "libzkmt.la" && ln -s "../libzkmt.la" "libzkmt.la" ) [exec] [exec] /bin/bash ./libtool --tag=CC --mode=link gcc -Wall -Werror -g -O2 -no-undefined -version-info 2 -o libzookeeper_mt.la -rpath http://hudson.zones.apache.org/hudson/job/Zookeeper-Patch-vesta.apache.org/ws/trunk/build/test/test-cppunit/lib libzkmt.la libhashtable.la -lpthread [exec] [exec] libtool: link: gcc -shared -Wl,--whole-archive ./.libs/libzkmt.a ./.libs/libhashtable.a -Wl,--no-whole-archive -lm -lpthread -Wl,-soname -Wl,libzookeeper_mt.so.2 -o .libs/libzookeeper_mt.so.2.0.0 [exec] [exec] libtool: link: (cd ".libs" && rm -f "libzookeeper_mt.so.2" && ln -s "libzookeeper_mt.so.2.0.0" "libzookeeper_mt.so.2") [exec] [exec] libtool: link: (cd ".libs" && rm -f "libzookeeper_mt.so" && ln -s "libzookeeper_mt.so.2.0.0" "libzookeeper_mt.so") [exec] [exec] libtool: link: (cd .libs/libzookeeper_mt.lax/libzkmt.a && ar x "http://hudson.zones.apache.org/hudson/job/Zookeeper-Patch-vesta.apache.org/ws/trunk/build/test/test-cppunit/./.libs/libzkmt.a";) [exec] [exec] libtool: link: (cd .libs/libzookeeper_mt.lax/libhashtable.a && ar x "http://hudson.zones.apache.org/hudson/job/Zookeeper-Patch-vesta.apache.org/ws/trunk/build/test/test-cppunit/./.libs/libhashtable.a";) [exec] [exec] libtool: link: ar cru .libs/libzookeeper_mt.a .libs/libzookeeper_mt.lax/libzkmt.a/libzkmt_la-zk_hashtable.o .libs/libzookeeper_mt.lax/libzkmt.a/libzkmt_la-zookeeper.jute.o .libs/libzookeeper_mt.lax/libzkmt.a/libzkmt_la-mt_adaptor.o .libs/libzookeeper_mt.lax/libzkmt.a/libzkmt_la-zk_log.o .libs/libzookeeper_mt.lax/libzkmt.a/libzkmt_la-recordio.o .libs/libzookeeper_mt.lax/libzkmt.a/libzkmt_la-zookeeper.o .libs/libzookeeper_mt.lax/libhashtable.a/hashtable_itr.o .libs/libzookeeper_mt.lax/libhashtable.a/hashtable.o [exec] [exec] libtool: link: ranlib .libs/libzookeeper_mt.a [exec] [exec] libtool: link: rm -fr .libs/libzookeeper_mt.lax [exec] [exec] libtool: link: ( cd ".libs" && rm -f "libzookeeper_mt.la" && ln -s "../libzookeeper_mt.la" "libzookeeper_mt.la" ) [exec] [exec] gcc -DHAVE_CONFIG_H -I. -Ihttp://hudson.zones.apache.org/hudson/job/Zookeeper-Patch-vesta.apache.org/ws/trunk/src/c -Ihttp://hudson.zones.apache.org/hudson/job/Zookeeper-Patch-vesta.apache.org/ws/trunk/src/c/include -Ihttp://hudson.zones.apache.org/hudson/job/Zookeeper-Patch-vesta.apache.org/ws/trunk/src/c/tests -Ihttp://hudson.zones.apache.org/hudson/job/Zookeeper-Patch-vesta.apache.org/ws/trunk/src/c/generated -Wall -Werror -g -O2 -MT cli.o -MD -MP -MF .deps/cli.Tpo -c -o cli.o `test -f 'src/cli.c' || echo 'http://hudson.zones.apache.org/hudson/job/Zookeeper-Patch-vesta.apache.org/ws/trunk/src/c/'`src/cli.c [exec] [exec] mv -f .deps/cli.Tpo .deps/cli.Po [exec] [exec] /bin/bash ./libtool --tag=CC --mode=link gcc -Wall -Werror -g -O2 -o cli_st cli.o libzookeeper_st.la [exec] [exec] libtool: link: gcc -Wall -Werror -g -O2 -o .libs/cli_st cli.o ./.libs/libzookeeper_st.so -lm -Wl,-rpath -Wl,http://hudson.zones.apache.org/hudson/job/Zookeeper-Patch-vesta.apache.org/ws/trunk/build/test/test-cppunit/lib [exec] [exec] gcc -DHAVE_CONFIG_H -I. -Ihttp://hudson.zones.apache.org/hudson/job/Zookeeper-Patch-vesta.apache.org/ws/trunk/src
[jira] Commented: (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:comment-tabpanel&focusedCommentId=12715793#action_12715793
]
Hadoop QA commented on ZOOKEEPER-196:
-
-1 overall. Here are the results of testing the latest attachment
http://issues.apache.org/jira/secure/attachment/12409690/ZOOKEEPER-196.patch
against trunk revision 781173.
+1 @author. The patch does not contain any @author tags.
-1 tests included. The patch doesn't appear to include any new or modified
tests.
Please justify why no tests are needed for this patch.
+1 javadoc. The javadoc tool did not generate any warning messages.
+1 javac. The applied patch does not increase the total number of javac
compiler warnings.
+1 findbugs. The patch does not introduce any new Findbugs warnings.
+1 release audit. The applied patch does not increase the total number of
release audit warnings.
+1 core tests. The patch passed core unit tests.
+1 contrib tests. The patch passed contrib unit tests.
Test results:
http://hudson.zones.apache.org/hudson/job/Zookeeper-Patch-vesta.apache.org/100/testReport/
Findbugs warnings:
http://hudson.zones.apache.org/hudson/job/Zookeeper-Patch-vesta.apache.org/100/artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html
Console output:
http://hudson.zones.apache.org/hudson/job/Zookeeper-Patch-vesta.apache.org/100/console
This message is automatically generated.
> 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
>Assignee: Benjamin Reed
> Fix For: 3.2.0
>
> Attachments: ZOOKEEPER-196.patch
>
>
> 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] Commented: (ZOOKEEPER-408) address all findbugs warnings in persistence classes
[ https://issues.apache.org/jira/browse/ZOOKEEPER-408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12715812#action_12715812 ] Benjamin Reed commented on ZOOKEEPER-408: - -1 turns out that SyncRequestProcessor.snapCount can't be final; tests try to set it. when i removed the final, ClientTest hangs > address all findbugs warnings in persistence classes > > > Key: ZOOKEEPER-408 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-408 > Project: Zookeeper > Issue Type: Sub-task >Reporter: Patrick Hunt >Assignee: Mahadev konar > Fix For: 3.2.0 > > Attachments: ZOOKEEPER-408.patch, ZOOKEEPER-408.patch, > ZOOKEEPER-408.patch > > > trunk/src/java/main/org/apache/zookeeper/server/DataTree.java > trunk/src/java/main/org/apache/zookeeper/server/persistence/FileTxnSnapLog.java > trunk/src/java/main/org/apache/zookeeper/server/persistence/FileTxnLog.java > trunk/src/java/main/org/apache/zookeeper/server/persistence/Util.java > trunk/src/java/main/org/apache/zookeeper/server/DataNode.java > trunk/src/java/main/org/apache/zookeeper/server/upgrade/DataNodeV1.java > trunk/src/java/main/org/apache/zookeeper/server/upgrade/DataTreeV1.java -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
