[jira] Commented: (ZOOKEEPER-543) Tests for ZooKeeper examples

2010-03-06 Thread Hadoop QA (JIRA)

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-543?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=1284#action_1284
 ] 

Hadoop QA commented on ZOOKEEPER-543:
-

+1 overall.  Here are the results of testing the latest attachment 
  http://issues.apache.org/jira/secure/attachment/12438085/ZOOKEEPER-543.patch
  against trunk revision 919706.

+1 @author.  The patch does not contain any @author tags.

+1 tests included.  The patch appears to include 3 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 passed core unit tests.

+1 contrib tests.  The patch passed contrib unit tests.

Test results: 
http://hudson.zones.apache.org/hudson/job/Zookeeper-Patch-h7.grid.sp2.yahoo.net/79/testReport/
Findbugs warnings: 
http://hudson.zones.apache.org/hudson/job/Zookeeper-Patch-h7.grid.sp2.yahoo.net/79/artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html
Console output: 
http://hudson.zones.apache.org/hudson/job/Zookeeper-Patch-h7.grid.sp2.yahoo.net/79/console

This message is automatically generated.

 Tests for ZooKeeper examples
 

 Key: ZOOKEEPER-543
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-543
 Project: Zookeeper
  Issue Type: New Feature
  Components: tests
Affects Versions: 3.3.0
Reporter: Steven Cheng
Assignee: Steven Cheng
Priority: Minor
 Fix For: 3.3.0

 Attachments: ZOOKEEPER-543.patch, ZOOKEEPER-543.patch, 
 ZOOKEEPER-543.patch, ZOOKEEPER-543.patch


 Initial attempt to create ZooKeeper tests based on the example code on the 
 website.  
 Current plan is to test features used in examples using ZooKeeper calls 
 directly.  Another approach would be to make more usable abstractions such as 
 those in src/recipes and test those.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Commented: (ZOOKEEPER-622) Test for pending watches in send_set_watches should be moved

2010-03-06 Thread Hudson (JIRA)

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12842243#action_12842243
 ] 

Hudson commented on ZOOKEEPER-622:
--

Integrated in ZooKeeper-trunk #716 (See 
[http://hudson.zones.apache.org/hudson/job/ZooKeeper-trunk/716/])
. Test for pending watches in send_set_watches should be moved (ben and 
steven via mahadev)


 Test for pending watches in send_set_watches should be moved
 

 Key: ZOOKEEPER-622
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-622
 Project: Zookeeper
  Issue Type: Bug
  Components: c client
Reporter: Steven Cheng
Assignee: Benjamin Reed
 Fix For: 3.3.0

 Attachments: ZOOKEEPER-622.patch, ZOOKEEPER-622.patch, 
 ZOOKEEPER-622.patch, ZOOKEEPER-622.patch


 Valgrind found:
 {quote}
 ==2357== Conditional jump or move depends on uninitialised value(s)
 ==2357==at 0x807FDCA: check_events (zookeeper.c:1180)
 ==2357==by 0x808043A: zookeeper_process (zookeeper.c:1775)
 ==2357==by 0x806A21B: Zookeeper_close::testCloseConnected1() 
 (TestZookeeperClose.cc:161)
 ==2357==by 0x806C6BF: CppUnit::TestCallerZookeeper_close::runTest() 
 (TestCaller.h:166)
 {quote}
 zookeeper.c:1180 was the first if in send_set_watches.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Commented: (ZOOKEEPER-688) explain session expiration better in the docs faq

2010-03-06 Thread Hudson (JIRA)

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12842242#action_12842242
 ] 

Hudson commented on ZOOKEEPER-688:
--

Integrated in ZooKeeper-trunk #716 (See 
[http://hudson.zones.apache.org/hudson/job/ZooKeeper-trunk/716/])
. explain session expiration better in the docs  faq (phunt via mahadev)


 explain session expiration better in the docs  faq
 ---

 Key: ZOOKEEPER-688
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-688
 Project: Zookeeper
  Issue Type: Bug
  Components: documentation
Reporter: Patrick Hunt
Assignee: Patrick Hunt
Priority: Critical
 Fix For: 3.3.0

 Attachments: ZOOKEEPER-688.patch, ZOOKEEPER-688.patch


 We are not clear enough (and the diagram we do have seems misleading) on 
 _when_ session expirations are generated. In particular the fact that you 
 only get expirations when the client is connected to the cluster, not when 
 disconnected.
 we need to detail:
 1) when do you get expiration
 2) what is the sequence of events that the watcher sees, from disco state, to 
 getting the expiration (say the expiration happens when the client is disco, 
 what do you see in the watcher while you are getting reconnected)
 3) we need to give some examples of how to test this. We should be explicit 
 that pulling the network cable on the client will not show expiration since 
 the cliient will not be reconnected.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Commented: (ZOOKEEPER-59) Synchronized block in NIOServerCnxn

2010-03-06 Thread Flavio Paiva Junqueira (JIRA)

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-59?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12842248#action_12842248
 ] 

Flavio Paiva Junqueira commented on ZOOKEEPER-59:
-

As I already mentioned above, I don't think it requires a test. Ben, could you 
please check my previous post to see if you agree?

 Synchronized block in NIOServerCnxn
 ---

 Key: ZOOKEEPER-59
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-59
 Project: Zookeeper
  Issue Type: Bug
  Components: server
Reporter: Flavio Paiva Junqueira
Assignee: Flavio Paiva Junqueira
 Fix For: 3.3.0

 Attachments: ZOOKEEPER-59.patch, ZOOKEEPER-59.patch


 There are two synchronized blocks locking on different objects, and to me 
 they should be guarded by the same object. Here are the parts of the code I'm 
 talking about:
 {noformat}
 nioservercnxn.readrequ...@444
 ...
   synchronized (this) {
 outstandingRequests++;
 // check throttling
 if (zk.getInProcess()  factory.outstandingLimit) {
 disableRecv();
 // following lines should not be needed since we are 
 already
 // reading
 // } else {
 // enableRecv();
 }
 } 
 {noformat}
 {noformat}
 nioservercnxn.sendrespo...@740
 ...
  synchronized (this.factory) {
 outstandingRequests--;
 // check throttling
 if (zk.getInProcess()  factory.outstandingLimit
 || outstandingRequests  1) {
 sk.selector().wakeup();
 enableRecv();
 }
 }
 {noformat}
 I think the second one is correct, and the first synchronized block should be 
 guarded by this.factory. 
 This could be related to issue ZOOKEEPER-57, but I have no concrete 
 indication that this is the case so far.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Commented: (ZOOKEEPER-59) Synchronized block in NIOServerCnxn

2010-03-06 Thread Benjamin Reed (JIRA)

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-59?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12842281#action_12842281
 ] 

Benjamin Reed commented on ZOOKEEPER-59:


ah yes, i see what you mean, but i think i would prefer a outstandingRequests 
that might be stale to a possible deadlock.

i agree that this doesn't need a test. this is a latent bug that is hard to be 
reproduced and a test would be very specific to the implementation of the bug.

 Synchronized block in NIOServerCnxn
 ---

 Key: ZOOKEEPER-59
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-59
 Project: Zookeeper
  Issue Type: Bug
  Components: server
Reporter: Flavio Paiva Junqueira
Assignee: Flavio Paiva Junqueira
 Fix For: 3.3.0

 Attachments: ZOOKEEPER-59.patch, ZOOKEEPER-59.patch


 There are two synchronized blocks locking on different objects, and to me 
 they should be guarded by the same object. Here are the parts of the code I'm 
 talking about:
 {noformat}
 nioservercnxn.readrequ...@444
 ...
   synchronized (this) {
 outstandingRequests++;
 // check throttling
 if (zk.getInProcess()  factory.outstandingLimit) {
 disableRecv();
 // following lines should not be needed since we are 
 already
 // reading
 // } else {
 // enableRecv();
 }
 } 
 {noformat}
 {noformat}
 nioservercnxn.sendrespo...@740
 ...
  synchronized (this.factory) {
 outstandingRequests--;
 // check throttling
 if (zk.getInProcess()  factory.outstandingLimit
 || outstandingRequests  1) {
 sk.selector().wakeup();
 enableRecv();
 }
 }
 {noformat}
 I think the second one is correct, and the first synchronized block should be 
 guarded by this.factory. 
 This could be related to issue ZOOKEEPER-57, but I have no concrete 
 indication that this is the case so far.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Updated: (ZOOKEEPER-678) Browser application to view and edit the contents of a zookeeper instance

2010-03-06 Thread Colin Goodheart-Smithe (JIRA)

 [ 
https://issues.apache.org/jira/browse/ZOOKEEPER-678?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Colin Goodheart-Smithe updated ZOOKEEPER-678:
-

Attachment: ZooInspector.zip

The submitted zip file contains the updates Patrick asked for.  The zip 
contains the zooinspector folder for the contrib folder.  It also contains the 
findbugs report and the RAT report.  The RAT report identifies 3 files without 
licence headers.  These are the EPL licence file and two .cfg files.  These 
files are generated by the application and are used for setting the defaults to 
use for connection settings and for the nodeviewers used on first start up.  Do 
these need licence headers since they are generated by the application?  The 
reason they need to be submitted is so that the defaults can be determined the 
first time the application is run.

 Browser application to view and edit the contents of a zookeeper instance
 -

 Key: ZOOKEEPER-678
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-678
 Project: Zookeeper
  Issue Type: New Feature
Affects Versions: 3.3.0
Reporter: Colin Goodheart-Smithe
Assignee: Colin Goodheart-Smithe
 Fix For: 3.3.0

 Attachments: zooInspector.sh, ZooInspector.zip, ZooInspector.zip, 
 ZooInspector.zip


 An application which shows a tree view of the nodes currently in a zookeeper 
 instance and allow the user to view and update the contents of the nodes as 
 well as allowing users to add and remove nodes from the tree, similar in use 
 to the Luke application in the Lucene project.
 I have a list of other features that I want to add to this application but I 
 wanted to gauge the response before I implemented them all.  I have found 
 this useful when debugging my application and thought that it may be useful 
 to others.
 I was going to submit this as a patch file but I have used some icon files 
 and one library which isn't available in the maven/ivy repositories and these 
 don't seem to work when creating a patch file using subversion.  Because of 
 this I have attached a zip containing this application to this issue.  If 
 there is a better way to submit this please let me know.
 The zip contains two directories, the src directory contains the source as it 
 would be added to the contrib folder and the build folder contains a build 
 version of the with a runnable jar.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.