[jira] Commented: (ZOOKEEPER-300) zk jmx code is calling printStackTrace when creating bean name (should not be)
[ https://issues.apache.org/jira/browse/ZOOKEEPER-300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12670960#action_12670960 ] Patrick Hunt commented on ZOOKEEPER-300: in the case of malformedobjectnameexception we should also catch/rethrow this exception at a low enough level such that we can log (WARN) the name that was invalid (sun doesn't include that in the error message and it would be useful) > zk jmx code is calling printStackTrace when creating bean name (should not be) > -- > > Key: ZOOKEEPER-300 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-300 > Project: Zookeeper > Issue Type: Bug >Affects Versions: 3.1.0 >Reporter: Patrick Hunt > Fix For: 3.2.0 > > > remove printStackTrace from zk jmx code (review the rest of the code at the > same time) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [VOTE] Release ZooKeeper 3.1.0 (candidate 1)
I don't suppose you are running on an IPv6 system? Patrick Patrick Hunt wrote: Hi Tom, this is unusual - what's your environment like? OS and java version string would help to debug (zk config?). Mahadev (mac) and I (ubuntu/redhat) both running recent versions of java6 have just tried this and we can't reproduce it. We use the IP address & sessionid as the name of the connection jmx bean, so this is weird: ip=connection.getRemoteAddress().getAddress().getHostAddress(); here's an example name I see in jconsole: org.apache.ZooKeeperService:name0=StandaloneServer_port-1,name1=Connections,name2=127.0.0.1,name3=0x11f489f8126 (btw, thank you sun for including the invalid name in the error message ;-) ) One thing I do notice is that printStackTrace is being called by our jmx code which should not be happening - that's why you are seeing this in on the console rather than just in the log (we log WARN then ignore the issue btw) . I'll enter a jira for this. https://issues.apache.org/jira/browse/ZOOKEEPER-300 Patrick Tom White wrote: I installed the candidate and got the following exception when performing some basic operations. The operations succeeded - it looks like a problem with JMX integration. Has anyone else seen this? Thanks, Tom $ bin/zkServer.sh start JMX enabled by default -n Starting zookeeper ... STARTED loy:zookeeper-3.1.0 tom$ javax.management.MalformedObjectNameException: Invalid character ':' in value part of property at javax.management.ObjectName.construct(ObjectName.java:602) at javax.management.ObjectName.(ObjectName.java:1394) at org.apache.zookeeper.jmx.MBeanRegistry.makeObjectName(MBeanRegistry.java:173) at org.apache.zookeeper.jmx.MBeanRegistry.register(MBeanRegistry.java:70) at org.apache.zookeeper.server.NIOServerCnxn.finishSessionInit(NIOServerCnxn.java:861) at org.apache.zookeeper.server.FinalRequestProcessor.processRequest(FinalRequestProcessor.java:145) at org.apache.zookeeper.server.SyncRequestProcessor.flush(SyncRequestProcessor.java:127) at org.apache.zookeeper.server.SyncRequestProcessor.run(SyncRequestProcessor.java:75) java.lang.IllegalArgumentException: Null object name at com.sun.jmx.mbeanserver.MXBeanSupport.register(MXBeanSupport.java:138) at com.sun.jmx.mbeanserver.MBeanSupport.preRegister2(MBeanSupport.java:183) at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerDynamicMBean(DefaultMBeanServerInterceptor.java:941) at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerObject(DefaultMBeanServerInterceptor.java:917) at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:312) at com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:482) at org.apache.zookeeper.jmx.MBeanRegistry.register(MBeanRegistry.java:72) at org.apache.zookeeper.server.NIOServerCnxn.finishSessionInit(NIOServerCnxn.java:861) at org.apache.zookeeper.server.FinalRequestProcessor.processRequest(FinalRequestProcessor.java:145) at org.apache.zookeeper.server.SyncRequestProcessor.flush(SyncRequestProcessor.java:127) at org.apache.zookeeper.server.SyncRequestProcessor.run(SyncRequestProcessor.java:75) On Thu, Feb 5, 2009 at 8:56 PM, Stu Hood wrote: +1 Thanks Patrick! -Original Message- From: "Patrick Hunt" Sent: Wednesday, February 4, 2009 6:33pm To: "zookeeper-dev@hadoop.apache.org" Subject: [VOTE] Release ZooKeeper 3.1.0 (candidate 1) I've created a new candidate (rc1) that fixes an issue raised by a user (thanks Stu!) during review: https://issues.apache.org/jira/browse/ZOOKEEPER-291 The release notes were also updated to reflect this change. Otw there are no other changes. *** Please download, test and VOTE before the *** vote closes EOD on Monday February 9.*** http://people.apache.org/~phunt/zookeeper-3.1.0-candidate-1/ Should we release this? Patrick
Re: [VOTE] Release ZooKeeper 3.1.0 (candidate 1)
Hi Tom, this is unusual - what's your environment like? OS and java version string would help to debug (zk config?). Mahadev (mac) and I (ubuntu/redhat) both running recent versions of java6 have just tried this and we can't reproduce it. We use the IP address & sessionid as the name of the connection jmx bean, so this is weird: ip=connection.getRemoteAddress().getAddress().getHostAddress(); here's an example name I see in jconsole: org.apache.ZooKeeperService:name0=StandaloneServer_port-1,name1=Connections,name2=127.0.0.1,name3=0x11f489f8126 (btw, thank you sun for including the invalid name in the error message ;-) ) One thing I do notice is that printStackTrace is being called by our jmx code which should not be happening - that's why you are seeing this in on the console rather than just in the log (we log WARN then ignore the issue btw) . I'll enter a jira for this. https://issues.apache.org/jira/browse/ZOOKEEPER-300 Patrick Tom White wrote: I installed the candidate and got the following exception when performing some basic operations. The operations succeeded - it looks like a problem with JMX integration. Has anyone else seen this? Thanks, Tom $ bin/zkServer.sh start JMX enabled by default -n Starting zookeeper ... STARTED loy:zookeeper-3.1.0 tom$ javax.management.MalformedObjectNameException: Invalid character ':' in value part of property at javax.management.ObjectName.construct(ObjectName.java:602) at javax.management.ObjectName.(ObjectName.java:1394) at org.apache.zookeeper.jmx.MBeanRegistry.makeObjectName(MBeanRegistry.java:173) at org.apache.zookeeper.jmx.MBeanRegistry.register(MBeanRegistry.java:70) at org.apache.zookeeper.server.NIOServerCnxn.finishSessionInit(NIOServerCnxn.java:861) at org.apache.zookeeper.server.FinalRequestProcessor.processRequest(FinalRequestProcessor.java:145) at org.apache.zookeeper.server.SyncRequestProcessor.flush(SyncRequestProcessor.java:127) at org.apache.zookeeper.server.SyncRequestProcessor.run(SyncRequestProcessor.java:75) java.lang.IllegalArgumentException: Null object name at com.sun.jmx.mbeanserver.MXBeanSupport.register(MXBeanSupport.java:138) at com.sun.jmx.mbeanserver.MBeanSupport.preRegister2(MBeanSupport.java:183) at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerDynamicMBean(DefaultMBeanServerInterceptor.java:941) at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerObject(DefaultMBeanServerInterceptor.java:917) at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:312) at com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:482) at org.apache.zookeeper.jmx.MBeanRegistry.register(MBeanRegistry.java:72) at org.apache.zookeeper.server.NIOServerCnxn.finishSessionInit(NIOServerCnxn.java:861) at org.apache.zookeeper.server.FinalRequestProcessor.processRequest(FinalRequestProcessor.java:145) at org.apache.zookeeper.server.SyncRequestProcessor.flush(SyncRequestProcessor.java:127) at org.apache.zookeeper.server.SyncRequestProcessor.run(SyncRequestProcessor.java:75) On Thu, Feb 5, 2009 at 8:56 PM, Stu Hood wrote: +1 Thanks Patrick! -Original Message- From: "Patrick Hunt" Sent: Wednesday, February 4, 2009 6:33pm To: "zookeeper-dev@hadoop.apache.org" Subject: [VOTE] Release ZooKeeper 3.1.0 (candidate 1) I've created a new candidate (rc1) that fixes an issue raised by a user (thanks Stu!) during review: https://issues.apache.org/jira/browse/ZOOKEEPER-291 The release notes were also updated to reflect this change. Otw there are no other changes. *** Please download, test and VOTE before the *** vote closes EOD on Monday February 9.*** http://people.apache.org/~phunt/zookeeper-3.1.0-candidate-1/ Should we release this? Patrick
[jira] Created: (ZOOKEEPER-300) zk jmx code is calling printStackTrace when creating bean name (should not be)
zk jmx code is calling printStackTrace when creating bean name (should not be) -- Key: ZOOKEEPER-300 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-300 Project: Zookeeper Issue Type: Bug Affects Versions: 3.1.0 Reporter: Patrick Hunt Fix For: 3.2.0 remove printStackTrace from zk jmx code (review the rest of the code at the same time) -- 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.
Re: [VOTE] Release ZooKeeper 3.1.0 (candidate 1)
I installed the candidate and got the following exception when performing some basic operations. The operations succeeded - it looks like a problem with JMX integration. Has anyone else seen this? Thanks, Tom $ bin/zkServer.sh start JMX enabled by default -n Starting zookeeper ... STARTED loy:zookeeper-3.1.0 tom$ javax.management.MalformedObjectNameException: Invalid character ':' in value part of property at javax.management.ObjectName.construct(ObjectName.java:602) at javax.management.ObjectName.(ObjectName.java:1394) at org.apache.zookeeper.jmx.MBeanRegistry.makeObjectName(MBeanRegistry.java:173) at org.apache.zookeeper.jmx.MBeanRegistry.register(MBeanRegistry.java:70) at org.apache.zookeeper.server.NIOServerCnxn.finishSessionInit(NIOServerCnxn.java:861) at org.apache.zookeeper.server.FinalRequestProcessor.processRequest(FinalRequestProcessor.java:145) at org.apache.zookeeper.server.SyncRequestProcessor.flush(SyncRequestProcessor.java:127) at org.apache.zookeeper.server.SyncRequestProcessor.run(SyncRequestProcessor.java:75) java.lang.IllegalArgumentException: Null object name at com.sun.jmx.mbeanserver.MXBeanSupport.register(MXBeanSupport.java:138) at com.sun.jmx.mbeanserver.MBeanSupport.preRegister2(MBeanSupport.java:183) at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerDynamicMBean(DefaultMBeanServerInterceptor.java:941) at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerObject(DefaultMBeanServerInterceptor.java:917) at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:312) at com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:482) at org.apache.zookeeper.jmx.MBeanRegistry.register(MBeanRegistry.java:72) at org.apache.zookeeper.server.NIOServerCnxn.finishSessionInit(NIOServerCnxn.java:861) at org.apache.zookeeper.server.FinalRequestProcessor.processRequest(FinalRequestProcessor.java:145) at org.apache.zookeeper.server.SyncRequestProcessor.flush(SyncRequestProcessor.java:127) at org.apache.zookeeper.server.SyncRequestProcessor.run(SyncRequestProcessor.java:75) On Thu, Feb 5, 2009 at 8:56 PM, Stu Hood wrote: > +1 > > Thanks Patrick! > > > -Original Message- > From: "Patrick Hunt" > Sent: Wednesday, February 4, 2009 6:33pm > To: "zookeeper-dev@hadoop.apache.org" > Subject: [VOTE] Release ZooKeeper 3.1.0 (candidate 1) > > I've created a new candidate (rc1) that fixes an issue raised by a user > (thanks Stu!) during review: > https://issues.apache.org/jira/browse/ZOOKEEPER-291 > The release notes were also updated to reflect this change. > > Otw there are no other changes. > > *** Please download, test and VOTE before the > *** vote closes EOD on Monday February 9.*** > > http://people.apache.org/~phunt/zookeeper-3.1.0-candidate-1/ > > Should we release this? > > Patrick > > > > >
[jira] Created: (ZOOKEEPER-298) some excecutables (scripts typ.) are not marked as such in tar generated by "ant tar"
some excecutables (scripts typ.) are not marked as such in tar generated by "ant tar" - Key: ZOOKEEPER-298 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-298 Project: Zookeeper Issue Type: Bug Components: build Affects Versions: 3.1.0 Reporter: Patrick Hunt Fix For: 3.2.0 The configure scripts in src/c, the zkServer.sh in src/c/test, and some of the other scripts are not marked as executable when running "ant tar". The build.xml should be updated to mark appropriately. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (ZOOKEEPER-297) centralize version numbering in the source/build
centralize version numbering in the source/build Key: ZOOKEEPER-297 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-297 Project: Zookeeper Issue Type: Improvement Components: build Affects Versions: 3.1.0 Reporter: Patrick Hunt Priority: Minor Fix For: 3.2.0 There are now three locations in the source repository that store the version number of the code: 1) build.xml 2) configure.ac 3) zookeeper_version.h these all have to be managed when releasing/branching/etc... would be better if there were just one place - at the very least the configure.ac should be used to generate the version for zookeeper_version.h. Can we do a better job (ie less) at this? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[VOTE] Release ZooKeeper 3.1.0 (candidate 2)
I've created a new candidate (rc2) that fixes an issue raised by a user (thanks Chris!) during review: https://issues.apache.org/jira/browse/ZOOKEEPER-293 The release notes were also updated to reflect this change. Otw there are no other changes. *** Please download, test and VOTE before the *** vote closes EOD on Tuesday February 10.*** http://people.apache.org/~phunt/zookeeper-3.1.0-candidate-2/ Should we release this? Patrick
[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.
RE: [VOTE] Release ZooKeeper 3.1.0 (candidate 1)
+1 Thanks Patrick! -Original Message- From: "Patrick Hunt" Sent: Wednesday, February 4, 2009 6:33pm To: "zookeeper-dev@hadoop.apache.org" Subject: [VOTE] Release ZooKeeper 3.1.0 (candidate 1) I've created a new candidate (rc1) that fixes an issue raised by a user (thanks Stu!) during review: https://issues.apache.org/jira/browse/ZOOKEEPER-291 The release notes were also updated to reflect this change. Otw there are no other changes. *** Please download, test and VOTE before the *** vote closes EOD on Monday February 9.*** http://people.apache.org/~phunt/zookeeper-3.1.0-candidate-1/ Should we release this? Patrick
[jira] Created: (ZOOKEEPER-296) adopt APR-style versioning and compatibility guidelines for C API
adopt APR-style versioning and compatibility guidelines for C API - Key: ZOOKEEPER-296 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-296 Project: Zookeeper Issue Type: Improvement Components: c client Reporter: Chris Darroch Per a recent discussion on the ZooKeeper users mailing list regarding the API/ABI change introduced in 3.1.0 by ZOOKEEPER-255, I would suggest going forwards that the project adopt the versioning and compatibility guidelines of the Apache Portable Runtime (APR) project. These are well documented here: http://apr.apache.org/versioning.html I'd also suggest adopting the parallel installation procedure used by APR. This would mean that, for example, as of version 4.0.0 the ZooKeeper C library would be installed as libzookeeper_mt-4.so and the include files would be installed as zookeeper-4/zookeeper.h, etc. The namespace cleanup I suggest in ZOOKEEPER-295 would fit well with such a change. I should also point out the (rather mysterious) intent of the GNU libtool versioning system for libraries; while many projects seem to disregard it, it does have some value: http://www.gnu.org/software/libtool/manual/html_node/Libtool-versioning.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-295) prevent multiple namespace pollution by C API
[ https://issues.apache.org/jira/browse/ZOOKEEPER-295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Patrick Hunt updated ZOOKEEPER-295: --- Fix Version/s: 4.0.0 sounds good for 4 > prevent multiple namespace pollution by C API > - > > Key: ZOOKEEPER-295 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-295 > Project: Zookeeper > Issue Type: Improvement > Components: c client >Affects Versions: 3.0.0, 3.0.1, 3.1.0 >Reporter: Chris Darroch > Fix For: 4.0.0 > > > The ZOOKEEPER-6 issue touched on the problem of namespace pollution by the > ZooKeeper C API; this report was closed but I don't think the problem has > actually been substantially resolved. > There are multiple namespaces to consider. First, the names of the C include > files should ideally have a common prefix, e.g., zoo_recordio.h, or else be > concatenated into a single zookeeper.h file. The zookeeper.jute.h include > file has a reasonably good name in this regard. > Second, all macros should ideally have a common prefix, e.g., ZOO_ or ZK_ or > ZOOKEEPER_. Currently many exported constants (not macros) have the ZOO_ > prefix, such as ZOO_PERM_READ, but error codes have a Z prefix, e.g., ZOK, > ZNOTEMPTY. > Third, all functions should ideally have a common prefix, e.g., zoo_ or zk_ > or zookeeper_. Many do already, but there is some variation, such as > zookeeper_init(), zookeeper_process(), and there are also a large number of > functions which have no prefix. These include many of the functions defined > in recordio.h and zookeeper.jute.h, such as get_buffer() and serialize_Id(). > Many others are simply used internally within the ZooKeeper C library and not > declared in an external include file, but still pollute the caller's > namespace, e.g., get_xid(), process_completions(), adaptor_init(), etc. All > external symbols in the libraries should have a common prefix. > Fourth, all structure and type definitions should also have a common prefix, > again, zoo_ or zk_ or zookeeper_. This is especially true of structures > which currently have very generic names such as Id, Stat, and ACL from > zookeeper.jute.h; buffer, iarchive, and oarchive from recordio.h; and > clientid_t and watcher_fn from zookeeper.h. The zhandle_t structure should > also be renamed to have the same prefix, e.g., zoo_handle_t. > The ZOOKEEPER-6 report includes the comment that the names in > zookeeper.jute.h will be difficult to change because they affect the Java > code and that there should be "limited exposure since jute naming starts with > caps". It would be nice to think so, but I fear that a structure named Id or > Stat is going to be pretty darn commonplace in other people's code. I would > strongly recommend revising the entire set file, function, macro, type and > structure names for 4.0.0. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (ZOOKEEPER-295) prevent multiple namespace pollution by C API
prevent multiple namespace pollution by C API - Key: ZOOKEEPER-295 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-295 Project: Zookeeper Issue Type: Improvement Components: c client Affects Versions: 3.0.1, 3.0.0, 3.1.0 Reporter: Chris Darroch The ZOOKEEPER-6 issue touched on the problem of namespace pollution by the ZooKeeper C API; this report was closed but I don't think the problem has actually been substantially resolved. There are multiple namespaces to consider. First, the names of the C include files should ideally have a common prefix, e.g., zoo_recordio.h, or else be concatenated into a single zookeeper.h file. The zookeeper.jute.h include file has a reasonably good name in this regard. Second, all macros should ideally have a common prefix, e.g., ZOO_ or ZK_ or ZOOKEEPER_. Currently many exported constants (not macros) have the ZOO_ prefix, such as ZOO_PERM_READ, but error codes have a Z prefix, e.g., ZOK, ZNOTEMPTY. Third, all functions should ideally have a common prefix, e.g., zoo_ or zk_ or zookeeper_. Many do already, but there is some variation, such as zookeeper_init(), zookeeper_process(), and there are also a large number of functions which have no prefix. These include many of the functions defined in recordio.h and zookeeper.jute.h, such as get_buffer() and serialize_Id(). Many others are simply used internally within the ZooKeeper C library and not declared in an external include file, but still pollute the caller's namespace, e.g., get_xid(), process_completions(), adaptor_init(), etc. All external symbols in the libraries should have a common prefix. Fourth, all structure and type definitions should also have a common prefix, again, zoo_ or zk_ or zookeeper_. This is especially true of structures which currently have very generic names such as Id, Stat, and ACL from zookeeper.jute.h; buffer, iarchive, and oarchive from recordio.h; and clientid_t and watcher_fn from zookeeper.h. The zhandle_t structure should also be renamed to have the same prefix, e.g., zoo_handle_t. The ZOOKEEPER-6 report includes the comment that the names in zookeeper.jute.h will be difficult to change because they affect the Java code and that there should be "limited exposure since jute naming starts with caps". It would be nice to think so, but I fear that a structure named Id or Stat is going to be pretty darn commonplace in other people's code. I would strongly recommend revising the entire set file, function, macro, type and structure names for 4.0.0. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-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-tabpanel&focusedCommentId=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 ] Patrick Hunt updated ZOOKEEPER-293: --- Attachment: ZOOKEEPER-293.patch Addressed the issues as desc. > 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 ] Patrick Hunt updated ZOOKEEPER-293: --- Status: Patch Available (was: Open) > 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-294) document or change memory allocations in C API completion handling
document or change memory allocations in C API completion handling -- Key: ZOOKEEPER-294 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-294 Project: Zookeeper Issue Type: Improvement Components: c client Affects Versions: 3.0.1, 3.0.0, 3.1.0 Reporter: Chris Darroch The C API zookeeper_process() function, which is used in the IO thread, generally copies data into memory locations provided by the caller (for example, when handling a string completion, it uses memcpy() to copy the string data into a user-provided buffer). However, when handling string-list and ACL-list completions, memory is allocated by deserialize_GetChildrenResponse() and deserialize_GetACLResponse(), respectively, but not released afterward. Instead it is passed back to the user. This implies the user is responsible for calling deallocate_GetChildrenResponse() or deallocate_GetACLResponse(), respectively. At a minimum, this needs to be extremely well-documented. Perhaps better, the user should be able to pass an allocation function and a parameter to be passed to it. Then this function can called repeatedly as a callback in order to allocate the necessary memory. However, this does assume that the user's allocation function is MT-safe; that requirement would need to be documented if this approach is taken. For example, when using the ZooKeeper C API with the Apache Portable Runtime, one would ideally be able to use APR memory pools for such allocation requests. To do that, the user could pass a wrapper function for apr_palloc() and a data parameter that included a private sub-pool. The sub-pool would be MT-safe so long as it is used exclusively by the IO thread. So, something like zoo_get_children(..., zoo_alloc_func *alloc_func, void *alloc_data). This would obviously be a change most appropriate for a major version release, e.g., 4.0.0. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-216) Improve logging in C client
[ https://issues.apache.org/jira/browse/ZOOKEEPER-216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12670859#action_12670859 ] Chris Darroch commented on ZOOKEEPER-216: - A few specific ideas and areas of concern. The threads spawned by a single connection handle may write to the log file at the same time. Personally, this doesn't concern me overmuch; I'd prefer not to have the logging subsystem doing a lot of mutex locking just to ensure the occasional log entries don't collide. More seriously, the logLevel and logStream variables in zk_log.c are global resources. That means if a program opens several ZooKeeper connections, they all share the file descriptor, and so all connection handles are affected if any part of the program changes the log file descriptor. There may also be a small possibility of collision that if one thread changes the log file descriptor while another is reading it (although it's just a pointer, so it depends on whether the pointer is updated atomically). At any rate, it would be excellent to have per-connection-handle logging attributes (level and stream). > Improve logging in C client > --- > > Key: ZOOKEEPER-216 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-216 > Project: Zookeeper > Issue Type: Improvement > Components: c client >Affects Versions: 3.0.0 >Reporter: Patrick Hunt > Fix For: 3.2.0 > > > While debugging a client issue we saw multiple areas for improvement in C > logging. > It might be a good idea to also move to log4c. Anyone have experience with > this? multithread an 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-293) zoo_set needs to be abi compatible (3.1 changed the signature), fix this by adding zoo_set2
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 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] Commented: (ZOOKEEPER-292) commit configure scripts (autotools) to svn for c projects and include in release
[ https://issues.apache.org/jira/browse/ZOOKEEPER-292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12670836#action_12670836 ] Patrick Hunt commented on ZOOKEEPER-292: Maxim, not sure what you mean by your comment feb5. When I run make CFLAGS=-O3 results in: gcc -DHAVE_CONFIG_H -I. -I. -I. -Iinclude -Igenerated -Wall -Werror -O3 -MT zookeeper.lo -MD -MP -MF .deps/zookeeper.Tpo -c src/zookeeper.c -fPIC -DPIC -o .libs/zookeeper.o rather than: (with just "make"): gcc -DHAVE_CONFIG_H -I. -I. -I. -Iinclude -Igenerated -Wall -Werror -g -O2 -MT zookeeper.lo -MD -MP -MF .deps/zookeeper.Tpo -c src/zookeeper.c -fPIC -DPIC -o .libs/zookeeper.o so for me the build does use this value when compiling. Could you be more explicit? > commit configure scripts (autotools) to svn for c projects and include in > release > - > > Key: ZOOKEEPER-292 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-292 > Project: Zookeeper > Issue Type: Improvement > Components: c client, contrib-zkfuse >Reporter: Patrick Hunt > Fix For: 3.2.0 > > > We currently don't include configure scripts, just the .ac file itself. This > means that users are required > to run "autoreconf; ./configure" rather than just configure. > We should commit the configure script(s) to svn (hadoop core does this btw) > for our autotools based projects (currently c client api and zkfuse). > Also these should be included in the build. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-290) Bad Address on Bookie
[
https://issues.apache.org/jira/browse/ZOOKEEPER-290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12670766#action_12670766
]
Flavio Paiva Junqueira commented on ZOOKEEPER-290:
--
I can't reproduce it reliably. but I can say that it only happened so far when
writing long entries (e.g., 64k).
> 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.2.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.
Build failed in Hudson: ZooKeeper-trunk #220
See http://hudson.zones.apache.org/hudson/job/ZooKeeper-trunk/220/changes Changes: [mahadev] ZOOKEEPER-291. regression for legacy code using KeeperException.Code constants (due to 246). (pat via mahadev) -- [...truncated 61570 lines...] [junit] 2009-02-05 11:48:29,159 - INFO [NIOServerCxn.Factory:33221:nioservercnxn$fact...@176] - NIOServerCnxn factory exited run method [junit] 2009-02-05 11:48:29,160 - INFO [main:finalrequestproces...@265] - shutdown of request processor complete [junit] 2009-02-05 11:48:29,160 - INFO [SyncThread:0:syncrequestproces...@117] - SyncRequestProcessor exited! [junit] 2009-02-05 11:48:29,160 - INFO [ProcessThread:-1:preprequestproces...@111] - PrepRequestProcessor exited loop! [junit] 2009-02-05 11:48:29,260 - INFO [main:clientb...@306] - STARTING server [junit] 2009-02-05 11:48:29,260 - INFO [main:zookeeperser...@156] - Created server [junit] 2009-02-05 11:48:29,261 - INFO [main:files...@71] - Reading snapshot http://hudson.zones.apache.org/hudson/job/ZooKeeper-trunk/ws/trunk/build/test/tmp/test9023421607589993707.junit.dir/version-2/snapshot.0 [junit] 2009-02-05 11:48:29,262 - INFO [main:filetxnsnap...@198] - Snapshotting: 3 [junit] 2009-02-05 11:48:29,264 - INFO [NIOServerCxn.Factory:33221:nioserverc...@621] - Processing stat command from /127.0.0.1:59956 [junit] 2009-02-05 11:48:29,265 - WARN [NIOServerCxn.Factory:33221:nioserverc...@417] - Exception causing close of session 0x0 due to java.io.IOException: closing [junit] 2009-02-05 11:48:29,265 - INFO [NIOServerCxn.Factory:33221:nioserverc...@752] - closing session:0x0 NIOServerCnxn: java.nio.channels.SocketChannel[connected local=/127.0.0.1:33221 remote=/127.0.0.1:59956] [junit] 2009-02-05 11:48:30,000 - INFO [SessionTracker:sessiontrackeri...@142] - SessionTrackerImpl exited loop! [junit] 2009-02-05 11:48:30,000 - INFO [SessionTracker:sessiontrackeri...@142] - SessionTrackerImpl exited loop! [junit] 2009-02-05 11:48:31,088 - INFO [main-SendThread:clientcnxn$sendthr...@800] - Attempting connection to server /127.0.0.1:33221 [junit] 2009-02-05 11:48:31,088 - INFO [main-SendThread:clientcnxn$sendthr...@716] - Priming connection to java.nio.channels.SocketChannel[connected local=/127.0.0.1:59957 remote=/127.0.0.1:33221] [junit] 2009-02-05 11:48:31,088 - INFO [main-SendThread:clientcnxn$sendthr...@868] - Server connection successful [junit] 2009-02-05 11:48:31,089 - INFO [NIOServerCxn.Factory:33221:nioserverc...@503] - Connected to /127.0.0.1:59957 lastZxid 3 [junit] 2009-02-05 11:48:31,089 - INFO [NIOServerCxn.Factory:33221:nioserverc...@880] - Finished init of 0x11f4644834d valid:true [junit] 2009-02-05 11:48:31,089 - INFO [NIOServerCxn.Factory:33221:nioserverc...@531] - Renewing session 0x11f4644834d [junit] 2009-02-05 11:49:05,104 - INFO [main:clientb...@300] - STOPPING server [junit] 2009-02-05 11:49:05,105 - INFO [main:nioserverc...@752] - closing session:0x11f4644834d NIOServerCnxn: java.nio.channels.SocketChannel[connected local=/127.0.0.1:33221 remote=/127.0.0.1:59957] [junit] 2009-02-05 11:49:05,105 - WARN [main-SendThread:clientcnxn$sendthr...@898] - Exception closing session 0x11f4644834d to sun.nio.ch.selectionkeyi...@15d3388 [junit] java.io.IOException: Read error rc = -1 java.nio.DirectByteBuffer[pos=0 lim=4 cap=4] [junit] at org.apache.zookeeper.ClientCnxn$SendThread.doIO(ClientCnxn.java:632) [junit] at org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:876) [junit] 2009-02-05 11:49:05,106 - INFO [NIOServerCxn.Factory:33221:nioservercnxn$fact...@176] - NIOServerCnxn factory exited run method [junit] 2009-02-05 11:49:05,106 - INFO [main:finalrequestproces...@265] - shutdown of request processor complete [junit] 2009-02-05 11:49:05,106 - INFO [SyncThread:0:syncrequestproces...@117] - SyncRequestProcessor exited! [junit] 2009-02-05 11:49:05,106 - INFO [ProcessThread:-1:preprequestproces...@111] - PrepRequestProcessor exited loop! [junit] 2009-02-05 11:49:05,206 - INFO [main:clientb...@306] - STARTING server [junit] 2009-02-05 11:49:05,206 - INFO [main:zookeeperser...@156] - Created server [junit] 2009-02-05 11:49:05,207 - INFO [main:files...@71] - Reading snapshot http://hudson.zones.apache.org/hudson/job/ZooKeeper-trunk/ws/trunk/build/test/tmp/test9023421607589993707.junit.dir/version-2/snapshot.3 [junit] 2009-02-05 11:49:05,209 - INFO [main:filetxnsnap...@198] - Snapshotting: 5 [junit] 2009-02-05 11:49:05,211 - INFO [NIOServerCxn.Factory:33221:nioserverc...@621] - Processing stat command from /127.0.0.1:59959 [junit] 2009-02-05 11:49:05,211 - WARN [NIOServerCxn.Factory:33221:nioserverc...@417] - Exception causing close of session 0x0 due to java.io.IOException: closing [junit] 2009-02-05 11:49:05,212 -
[jira] Commented: (ZOOKEEPER-292) commit configure scripts (autotools) to svn for c projects and include in release
[ https://issues.apache.org/jira/browse/ZOOKEEPER-292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12670712#action_12670712 ] Maxim P. Dementiev commented on ZOOKEEPER-292: -- Patrick, sorry for my perseverance but... What about CFLAGS and CXXFLAGS? Build system doesn't take them into account. Should I create an issue (jira item) for this? > commit configure scripts (autotools) to svn for c projects and include in > release > - > > Key: ZOOKEEPER-292 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-292 > Project: Zookeeper > Issue Type: Improvement > Components: c client, contrib-zkfuse >Reporter: Patrick Hunt > Fix For: 3.2.0 > > > We currently don't include configure scripts, just the .ac file itself. This > means that users are required > to run "autoreconf; ./configure" rather than just configure. > We should commit the configure script(s) to svn (hadoop core does this btw) > for our autotools based projects (currently c client api and zkfuse). > Also these should be included in the build. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
