[jira] Commented: (ZOOKEEPER-223) default log4j root logger configuration has neg perf impact with no benefit, change default level to INFO
[ https://issues.apache.org/jira/browse/ZOOKEEPER-223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12649317#action_12649317 ] Hudson commented on ZOOKEEPER-223: -- Integrated in ZooKeeper-trunk #149 (See [http://hudson.zones.apache.org/hudson/job/ZooKeeper-trunk/149/]) > default log4j root logger configuration has neg perf impact with no benefit, > change default level to INFO > - > > Key: ZOOKEEPER-223 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-223 > Project: Zookeeper > Issue Type: Improvement > Components: java client, server >Affects Versions: 3.0.0 >Reporter: Patrick Hunt >Assignee: Patrick Hunt > Fix For: 3.0.1, 3.1.0 > > Attachments: ZOOKEEPER-223.patch > > > The default log4j.properties has: > log4j.rootLogger=DEBUG, CONSOLE > where the console appender is only outputting INFO level and above. > This is resulting in a large number of debug logs being generated, which are > all filtered out by the console appender (by default there are no other > appenders used) > We need to change the default rootLogger to INFO level, which will resolve > this issue. > Users are free to change this of course -- most likely they would only do > this when debugging an issue, and would not want to run in DEBUG in > production (again, they are free to choose). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-208) Zookeeper C client uses API that are not thread safe, causing crashes when multiple instances are active
[ https://issues.apache.org/jira/browse/ZOOKEEPER-208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12649316#action_12649316 ] Hudson commented on ZOOKEEPER-208: -- Integrated in ZooKeeper-trunk #149 (See [http://hudson.zones.apache.org/hudson/job/ZooKeeper-trunk/149/]) . Zookeeper C client uses API that are not thread safe, causing crashes when multiple instances are active. (austin shoemaker, chris daroch and ben reed via mahadev) > Zookeeper C client uses API that are not thread safe, causing crashes when > multiple instances are active > > > Key: ZOOKEEPER-208 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-208 > Project: Zookeeper > Issue Type: Bug > Components: c client >Affects Versions: 3.0.0 > Environment: Linux >Reporter: Austin Shoemaker >Assignee: Austin Shoemaker >Priority: Critical > Fix For: 3.0.1, 3.1.0 > > Attachments: ZOOKEEPER-208.patch, > zookeeper-strtok_getaddrinfo-trunk.patch, > zookeeper-strtok_getaddrinfo-trunk.patch > > > The Zookeeper C client library uses gethostbyname and strtok, both of which > are not safe to use from multiple threads. > The problem is resolved by using getaddrinfo and strtok_r in place of the > older API. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-218) error in barrier recipe example code
[ https://issues.apache.org/jira/browse/ZOOKEEPER-218?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12649314#action_12649314 ] Hudson commented on ZOOKEEPER-218: -- Integrated in ZooKeeper-trunk #149 (See [http://hudson.zones.apache.org/hudson/job/ZooKeeper-trunk/149/]) > error in barrier recipe example code > > > Key: ZOOKEEPER-218 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-218 > Project: Zookeeper > Issue Type: Bug > Components: documentation >Affects Versions: 3.0.0 >Reporter: Patrick Hunt >Assignee: Patrick Hunt > Fix For: 3.0.1, 3.1.0 > > Attachments: ZOOKEEPER-218.patch > > > Report from user Murali Vemulapati. The wiki recipe page also should be > updated to handle multiple clients using the barrier on the same system > (multiple processes, etc...). Currently the docs/example support only a > single user of the barrier per host. > -- > I believe there is a typo in the barrier example given at: > http://hadoop.apache.org/zookeeper/docs/current/zookeeperTutorial.html > With the following fix, the program runs as expected: > == > 83c83 > < this.name = new > String(InetAddress.getLocalHost().getCanonicalHostName().toString()); > --- > > name = new > > String(InetAddress.getLocalHost().getCanonicalHostName().toString()); > 100c100 > < CreateMode.EPHEMERAL_SEQUENTIAL); > --- > > CreateMode.EPHEMERAL); > == > The first change assigns the name to the instance variable 'name' of Barrier > class (otherwise the 'name' instance variable will have a value of 'null' > when calling zk.create to create the child node under the root barrier node). > The second change lets us run multiple processes on the same machine. > thanks > murali -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-206) documentation tab should contain the version number (and other small site changes)
[ https://issues.apache.org/jira/browse/ZOOKEEPER-206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12649318#action_12649318 ] Hudson commented on ZOOKEEPER-206: -- Integrated in ZooKeeper-trunk #149 (See [http://hudson.zones.apache.org/hudson/job/ZooKeeper-trunk/149/]) > documentation tab should contain the version number (and other small site > changes) > --- > > Key: ZOOKEEPER-206 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-206 > Project: Zookeeper > Issue Type: Bug > Components: documentation >Affects Versions: 3.0.0 >Reporter: Patrick Hunt >Assignee: Patrick Hunt >Priority: Minor > Fix For: 3.0.1, 3.1.0 > > Attachments: ZOOKEEPER-206_301.patch, ZOOKEEPER-206_trunk.patch > > > Feedback from Doug Cutting on 3.0.0 documentation: > - The "Zookeeper Documentation" tab should contain the version number. > - "Informal Documentation" might better be named "Other Documentation". > - The "Other Info" page should be removed, since it contains nothing. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-217) handle errors when parsing config file, throw illegalargumentexception rather than exit()
[ https://issues.apache.org/jira/browse/ZOOKEEPER-217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12649319#action_12649319 ] Hudson commented on ZOOKEEPER-217: -- Integrated in ZooKeeper-trunk #149 (See [http://hudson.zones.apache.org/hudson/job/ZooKeeper-trunk/149/]) > handle errors when parsing config file, throw illegalargumentexception rather > than exit() > - > > Key: ZOOKEEPER-217 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-217 > Project: Zookeeper > Issue Type: Improvement > Components: server >Affects Versions: 3.0.0 >Reporter: Flavio Paiva Junqueira >Assignee: Mahadev konar >Priority: Minor > Fix For: 3.0.1, 3.1.0 > > Attachments: ZOOKEEPER-217.patch, ZOOKEEPER-217.patch > > > Discussing 209 with Ben today, we thought that it would be better to have the > parse method of QuorumPeerConfig returning a boolean that indicates whether > the configuration is good or not, and let the caller decide whether to exit > or not. Currently we execute a System.exit() on QuorumPeerConfig.parse when > we have a critical configuration error. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-213) programmer guide C api docs are out of sync with latest zookeeper.h
[ https://issues.apache.org/jira/browse/ZOOKEEPER-213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12649326#action_12649326 ] Hudson commented on ZOOKEEPER-213: -- Integrated in ZooKeeper-trunk #149 (See [http://hudson.zones.apache.org/hudson/job/ZooKeeper-trunk/149/]) > programmer guide C api docs are out of sync with latest zookeeper.h > > > Key: ZOOKEEPER-213 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-213 > Project: Zookeeper > Issue Type: Bug > Components: documentation >Affects Versions: 3.0.0 >Reporter: Patrick Hunt >Assignee: Patrick Hunt > Fix For: 3.0.1, 3.1.0 > > Attachments: ZOOKEEPER-213.patch > > > see > http://hadoop.apache.org/zookeeper/docs/current/zookeeperProgrammers.html#Zookeeper+C+client+API > and compare with src/c/zookeeper.h -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Hudson build is back to normal: ZooKeeper-trunk #149
See http://hudson.zones.apache.org/hudson/job/ZooKeeper-trunk/149/changes
[jira] Commented: (ZOOKEEPER-219) events.poll timeout in watcher test too short
[ https://issues.apache.org/jira/browse/ZOOKEEPER-219?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12649315#action_12649315 ] Hudson commented on ZOOKEEPER-219: -- Integrated in ZooKeeper-trunk #149 (See [http://hudson.zones.apache.org/hudson/job/ZooKeeper-trunk/149/]) > events.poll timeout in watcher test too short > - > > Key: ZOOKEEPER-219 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-219 > Project: Zookeeper > Issue Type: Bug >Affects Versions: 3.0.0 >Reporter: Patrick Hunt >Assignee: Patrick Hunt >Priority: Minor > Fix For: 3.0.1, 3.1.0 > > Attachments: ZOOKEEPER-219.patch > > > in watchertest there are some event.poll calls that have 1milli timeouts > e = localWatcher.events.poll(1, TimeUnit.MILLISECONDS); > this is showing falure in some cases under hudson (I assume when it's under > load from other tests running for other proj) > We should review the poll calls and verify adequate timeouts. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-212) snapshot is synchronous in 3.0
[ https://issues.apache.org/jira/browse/ZOOKEEPER-212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12649324#action_12649324 ] Hudson commented on ZOOKEEPER-212: -- Integrated in ZooKeeper-trunk #149 (See [http://hudson.zones.apache.org/hudson/job/ZooKeeper-trunk/149/]) > snapshot is synchronous in 3.0 > -- > > Key: ZOOKEEPER-212 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-212 > Project: Zookeeper > Issue Type: Bug >Affects Versions: 3.0.0 >Reporter: Mahadev konar >Assignee: Mahadev konar >Priority: Critical > Fix For: 3.0.1, 3.1.0 > > Attachments: ZOOKEEPER-212-test.patch, ZOOKEEPER-212.patch, > ZOOKEEPER-212.patch > > > the snapshot in 3.0 is syunchronous. this will affect performance of the > system. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-204) SetWatches needs to be the first message after auth messages to the server
[ https://issues.apache.org/jira/browse/ZOOKEEPER-204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12649320#action_12649320 ] Hudson commented on ZOOKEEPER-204: -- Integrated in ZooKeeper-trunk #149 (See [http://hudson.zones.apache.org/hudson/job/ZooKeeper-trunk/149/]) > SetWatches needs to be the first message after auth messages to the server > -- > > Key: ZOOKEEPER-204 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-204 > Project: Zookeeper > Issue Type: Bug > Components: java client >Affects Versions: 3.0.0 >Reporter: Benjamin Reed >Assignee: Benjamin Reed > Fix For: 3.0.1, 3.1.0 > > Attachments: ZOOKEEPER-204.patch, ZOOKEEPER-204.patch, > ZOOKEEPER-204.patch, ZOOKEEPER-204.patch > > > When the ZooKeeper java client makes a connection it queues a SetWatches > request. The problem is that it puts the request at the end of the outgoing > requests. This means that watches for requests that were queued before the > connection is made and after the disconnect may improperly get their watches > triggered. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-211) Not all Mock tests are working
[ https://issues.apache.org/jira/browse/ZOOKEEPER-211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12649323#action_12649323 ] Hudson commented on ZOOKEEPER-211: -- Integrated in ZooKeeper-trunk #149 (See [http://hudson.zones.apache.org/hudson/job/ZooKeeper-trunk/149/]) > Not all Mock tests are working > -- > > Key: ZOOKEEPER-211 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-211 > Project: Zookeeper > Issue Type: Test > Components: c client >Reporter: Benjamin Reed >Assignee: Benjamin Reed >Priority: Minor > Fix For: 3.0.1, 3.1.0 > > Attachments: ZOOKEEPER-211.patch > > > For the 3.0 release there was a bug in the ZKMock code that prevented some > tests from working. This patch fixes the bug and reenables the tests. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-226) exists calls fails on server if node has null data
[ https://issues.apache.org/jira/browse/ZOOKEEPER-226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12649325#action_12649325 ] Hudson commented on ZOOKEEPER-226: -- Integrated in ZooKeeper-trunk #149 (See [http://hudson.zones.apache.org/hudson/job/ZooKeeper-trunk/149/]) > exists calls fails on server if node has null data > -- > > Key: ZOOKEEPER-226 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-226 > Project: Zookeeper > Issue Type: Bug > Components: server >Affects Versions: 3.0.0 >Reporter: Patrick Hunt >Assignee: Mahadev konar >Priority: Blocker > Fix For: 3.0.1, 3.1.0 > > Attachments: ZOOKEEPER-226.patch > > > An NPE will be generated on the server (and resulting in client getting > MarshallingException) if exists() is called on a node with null data. > workaround is to create the node with non-null data. > be sure to update the tests for this case -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-228) apache header missing in DBtest
[ https://issues.apache.org/jira/browse/ZOOKEEPER-228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12649322#action_12649322 ] Hudson commented on ZOOKEEPER-228: -- Integrated in ZooKeeper-trunk #149 (See [http://hudson.zones.apache.org/hudson/job/ZooKeeper-trunk/149/]) > apache header missing in DBtest > --- > > Key: ZOOKEEPER-228 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-228 > Project: Zookeeper > Issue Type: Bug >Affects Versions: 3.0.0 >Reporter: Mahadev konar >Assignee: Mahadev konar >Priority: Blocker > Fix For: 3.0.1, 3.1.0 > > Attachments: ZOOKEEPER-228.patch > > > one of the test files is missing apache headers ... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-227) gcc warning from recordio.h
[ https://issues.apache.org/jira/browse/ZOOKEEPER-227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12649321#action_12649321 ] Hudson commented on ZOOKEEPER-227: -- Integrated in ZooKeeper-trunk #149 (See [http://hudson.zones.apache.org/hudson/job/ZooKeeper-trunk/149/]) . gcc warning from recordio.h (chris darroch via mahadev) > gcc warning from recordio.h > --- > > Key: ZOOKEEPER-227 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-227 > Project: Zookeeper > Issue Type: Bug > Components: c client >Affects Versions: 3.0.0 >Reporter: Chris Darroch >Assignee: Chris Darroch >Priority: Minor > Fix For: 3.0.1, 3.1.0 > > Attachments: zookeeper-recordio-trunk.patch > > > Recent gcc compilers issue warnings when function declarations for functions > with no arguments don't specific "void". The attached patch fixes one such > warning for create_buffer_oarchive() in recordio.h. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (ZOOKEEPER-230) Improvements to FLE
Improvements to FLE --- Key: ZOOKEEPER-230 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-230 Project: Zookeeper Issue Type: Improvement Components: leaderElection Affects Versions: 3.1.0 Reporter: Flavio Paiva Junqueira Assignee: Flavio Paiva Junqueira Fix For: 3.0.0 I'm about to attach a patch that implements the following modifications: . Currently, if a server is on leader election and doesn't receive a notification for some amount of time t, then it sends a new set of notifications if at least one server has delivered a message from the previous set. With this patch, the amount of time a server waits for a notification before sending a new set increases exponentially; . I have separated connecting to servers and queuing new notification messages. Before they were all in the same message. The advantage is that now I can tell to an instance of QuorumCnxManager to try to connect to other servers without generating new notification messages; . I have changed the logging level of several messages on QuorumCnxManager. They were "warn", but they should really be either "info" or "debug". I've changed them to info. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-230) Improvements to FLE
[ https://issues.apache.org/jira/browse/ZOOKEEPER-230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Flavio Paiva Junqueira updated ZOOKEEPER-230: - Status: Patch Available (was: Open) > Improvements to FLE > --- > > Key: ZOOKEEPER-230 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-230 > Project: Zookeeper > Issue Type: Improvement > Components: leaderElection >Affects Versions: 3.1.0 >Reporter: Flavio Paiva Junqueira >Assignee: Flavio Paiva Junqueira > Fix For: 3.0.0 > > Attachments: ZOOKEEPER-230.patch > > > I'm about to attach a patch that implements the following modifications: > . Currently, if a server is on leader election and doesn't receive a > notification for some amount of time t, then it sends a new set of > notifications if at least one server has delivered a message from the > previous set. With this patch, the amount of time a server waits for a > notification before sending a new set increases exponentially; > . I have separated connecting to servers and queuing new notification > messages. Before they were all in the same message. The advantage is that now > I can tell to an instance of QuorumCnxManager to try to connect to other > servers without generating new notification messages; > . I have changed the logging level of several messages on QuorumCnxManager. > They were "warn", but they should really be either "info" or "debug". I've > changed them to info. > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-230) Improvements to FLE
[ https://issues.apache.org/jira/browse/ZOOKEEPER-230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Flavio Paiva Junqueira updated ZOOKEEPER-230: - Attachment: ZOOKEEPER-230.patch > Improvements to FLE > --- > > Key: ZOOKEEPER-230 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-230 > Project: Zookeeper > Issue Type: Improvement > Components: leaderElection >Affects Versions: 3.1.0 >Reporter: Flavio Paiva Junqueira >Assignee: Flavio Paiva Junqueira > Fix For: 3.0.0 > > Attachments: ZOOKEEPER-230.patch > > > I'm about to attach a patch that implements the following modifications: > . Currently, if a server is on leader election and doesn't receive a > notification for some amount of time t, then it sends a new set of > notifications if at least one server has delivered a message from the > previous set. With this patch, the amount of time a server waits for a > notification before sending a new set increases exponentially; > . I have separated connecting to servers and queuing new notification > messages. Before they were all in the same message. The advantage is that now > I can tell to an instance of QuorumCnxManager to try to connect to other > servers without generating new notification messages; > . I have changed the logging level of several messages on QuorumCnxManager. > They were "warn", but they should really be either "info" or "debug". I've > changed them to info. > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (ZOOKEEPER-230) Improvements to FLE
[ https://issues.apache.org/jira/browse/ZOOKEEPER-230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mahadev konar updated ZOOKEEPER-230: Affects Version/s: (was: 3.1.0) 3.0.0 Fix Version/s: (was: 3.0.0) 3.1.0 i think you interchanged the fix and affects versions :) . > Improvements to FLE > --- > > Key: ZOOKEEPER-230 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-230 > Project: Zookeeper > Issue Type: Improvement > Components: leaderElection >Affects Versions: 3.0.0 >Reporter: Flavio Paiva Junqueira >Assignee: Flavio Paiva Junqueira > Fix For: 3.1.0 > > Attachments: ZOOKEEPER-230.patch > > > I'm about to attach a patch that implements the following modifications: > . Currently, if a server is on leader election and doesn't receive a > notification for some amount of time t, then it sends a new set of > notifications if at least one server has delivered a message from the > previous set. With this patch, the amount of time a server waits for a > notification before sending a new set increases exponentially; > . I have separated connecting to servers and queuing new notification > messages. Before they were all in the same message. The advantage is that now > I can tell to an instance of QuorumCnxManager to try to connect to other > servers without generating new notification messages; > . I have changed the logging level of several messages on QuorumCnxManager. > They were "warn", but they should really be either "info" or "debug". I've > changed them to info. > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
