[jira] Commented: (ZOOKEEPER-507) BookKeeper client re-write

[Benjamin Reed (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12803640#action_12803640
 ] 

Benjamin Reed commented on ZOOKEEPER-507:
-

here are the main changes:

1) changed to using netty for client requests
2) made recovery more reliable
3)  multiplexed writes to handle a large number of concurrent ledgers being 
written to

the user facing changes are minimal. our javadoc efforts have been with respect 
to user facing classes. the internal code is still a bit influx, so some of the 
internal or simple classes we have not put a lot of effort into documenting 
since they haven't really finalized.

our main goal right now is to get the patch in since it is very large and hard 
to manage at this point.

> BookKeeper client re-write
> --
>
> Key: ZOOKEEPER-507
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-507
> Project: Zookeeper
>  Issue Type: Improvement
>  Components: contrib-bookkeeper
>Reporter: Flavio Paiva Junqueira
>Assignee: Utkarsh Srivastava
> Fix For: 3.3.0
>
> Attachments: BookieFailureTest-log-507.rtf, ZOOKEEPER-507.patch, 
> ZOOKEEPER-507.patch, ZOOKEEPER-507.patch, ZOOKEEPER-507.patch
>
>
> Error handling is far from ideal currently in the BookKeeper client.

-- 
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 #675

[Apache Hudson Server]

See 

Changes:

[mahadev] ZOOKEEPER-626. ensure the c/java cli's print xid/sessionid/etc... in 
hex (pat via mahadev)

[henry] ZOOKEEPER-648. Fix releaseaudit warning count to zero (phunt via henry)

--
[...truncated 243705 lines...]
[junit] 2010-01-22 11:01:45,440 - INFO  [Snapshot 
Thread:filetxnsnap...@208] - Snapshotting: 20757
[junit] 2010-01-22 11:01:45,548 - INFO  [Snapshot 
Thread:filetxnsnap...@208] - Snapshotting: 20780
[junit] 2010-01-22 11:01:45,561 - INFO  [Snapshot 
Thread:filetxnsnap...@208] - Snapshotting: 20784
[junit] 2010-01-22 11:01:45,619 - INFO  [Snapshot 
Thread:filetxnsnap...@208] - Snapshotting: 20791
[junit] 2010-01-22 11:01:45,720 - INFO  [Snapshot 
Thread:filetxnsnap...@208] - Snapshotting: 207b0
[junit] 2010-01-22 11:01:45,759 - INFO  [Snapshot 
Thread:filetxnsnap...@208] - Snapshotting: 207b9
[junit] 2010-01-22 11:01:45,786 - INFO  [Snapshot 
Thread:filetxnsnap...@208] - Snapshotting: 207c3
[junit] 2010-01-22 11:01:45,846 - INFO  
[ProcessThread:-1:preprequestproces...@385] - Processed session termination for 
sessionid: 0x42655b1bdb6
[junit] 2010-01-22 11:01:45,849 - INFO  [main:zookee...@525] - Session: 
0x42655b1bdb6 closed
[junit] 2010-01-22 11:01:45,849 - INFO  
[NIOServerCxn.Factory:11226:nioserverc...@995] - Closed socket connection for 
client /127.0.0.1:59598 which had sessionid 0x42655b1bdb6
[junit] 2010-01-22 11:01:45,849 - INFO  [main:follo...@166] - shutdown 
called
[junit] java.lang.Exception: shutdown Follower
[junit] at 
org.apache.zookeeper.server.quorum.Follower.shutdown(Follower.java:166)
[junit] at 
org.apache.zookeeper.server.quorum.QuorumPeer.shutdown(QuorumPeer.java:668)
[junit] at 
org.apache.zookeeper.test.ZkDatabaseCorruptionTest.testCorruption(ZkDatabaseCorruptionTest.java:125)
[junit] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[junit] at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
[junit] at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
[junit] at java.lang.reflect.Method.invoke(Method.java:597)
[junit] at junit.framework.TestCase.runTest(TestCase.java:168)
[junit] at junit.framework.TestCase.runBare(TestCase.java:134)
[junit] at junit.framework.TestResult$1.protect(TestResult.java:110)
[junit] at junit.framework.TestResult.runProtected(TestResult.java:128)
[junit] at junit.framework.TestResult.run(TestResult.java:113)
[junit] at junit.framework.TestCase.run(TestCase.java:124)
[junit] at junit.framework.TestSuite.runTest(TestSuite.java:232)
[junit] at junit.framework.TestSuite.run(TestSuite.java:227)
[junit] at 
org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:83)
[junit] at 
junit.framework.JUnit4TestAdapter.run(JUnit4TestAdapter.java:39)
[junit] at 
org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:421)
[junit] at 
org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.launch(JUnitTestRunner.java:912)
[junit] at 
org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:766)
[junit] 2010-01-22 11:01:45,850 - INFO  [main:finalrequestproces...@366] - 
shutdown of request processor complete
[junit] 2010-01-22 11:01:45,850 - INFO  
[CommitProcessor:1:commitproces...@148] - CommitProcessor exited loop!
[junit] 2010-01-22 11:01:45,850 - INFO  
[FollowerRequestProcessor:1:followerrequestproces...@93] - 
FollowerRequestProcessor exited loop!
[junit] 2010-01-22 11:01:45,851 - INFO  
[SyncThread:1:syncrequestproces...@151] - SyncRequestProcessor exited!
[junit] 2010-01-22 11:01:45,851 - INFO  
[NIOServerCxn.Factory:11223:nioservercnxn$fact...@264] - NIOServerCnxn factory 
exited run method
[junit] 2010-01-22 11:01:45,851 - INFO  [main:follo...@166] - shutdown 
called
[junit] java.lang.Exception: shutdown Follower
[junit] at 
org.apache.zookeeper.server.quorum.Follower.shutdown(Follower.java:166)
[junit] at 
org.apache.zookeeper.server.quorum.QuorumPeer.shutdown(QuorumPeer.java:668)
[junit] at 
org.apache.zookeeper.test.ZkDatabaseCorruptionTest.testCorruption(ZkDatabaseCorruptionTest.java:126)
[junit] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[junit] at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
[junit] at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
[junit] at java.lang.reflect.Method.invoke(Method.java:597)
[junit] at junit.framework.TestCase.runTest(TestCase.java:168)
[junit] at junit.framework.TestCase.runBare(TestCase

[jira] Created: (ZOOKEEPER-652) package server and client separately

[zhouyanming (JIRA)]

package server and client separately


 Key: ZOOKEEPER-652
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-652
 Project: Zookeeper
  Issue Type: Improvement
  Components: build
Reporter: zhouyanming


is it possible split zookeeper.jar to zookeeper-server.jar and 
zookeeper-client.jar?
so app can only use client jar 

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

[jira] Commented: (ZOOKEEPER-652) package server and client separately

[Yonik Seeley (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12803701#action_12803701
 ] 

Yonik Seeley commented on ZOOKEEPER-652:


I sort of like the fact that everything you need is in one jar.
Although not including the source code in the jar might be nice to reduce it's 
size.

> package server and client separately
> 
>
> Key: ZOOKEEPER-652
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-652
> Project: Zookeeper
>  Issue Type: Improvement
>  Components: build
>Reporter: zhouyanming
>
> is it possible split zookeeper.jar to zookeeper-server.jar and 
> zookeeper-client.jar?
> so app can only use client jar 

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

[jira] Commented: (ZOOKEEPER-652) package server and client separately

[Benjamin Reed (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12803718#action_12803718
 ] 

Benjamin Reed commented on ZOOKEEPER-652:
-

it is definitely nice to have client code in the server jar so that you always 
have a client to do problem determination. is the purpose to make the client 
jar smaller?

> package server and client separately
> 
>
> Key: ZOOKEEPER-652
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-652
> Project: Zookeeper
>  Issue Type: Improvement
>  Components: build
>Reporter: zhouyanming
>
> is it possible split zookeeper.jar to zookeeper-server.jar and 
> zookeeper-client.jar?
> so app can only use client jar 

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

[jira] Updated: (ZOOKEEPER-537) The zookeeper jar includes the java source files

[Patrick Hunt (JIRA)]

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

Patrick Hunt updated ZOOKEEPER-537:
---

Component/s: build

> The zookeeper jar includes the java source files
> 
>
> Key: ZOOKEEPER-537
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-537
> Project: Zookeeper
>  Issue Type: Bug
>  Components: build
>Affects Versions: 3.3.0
>Reporter: Thomas Dudziak
>Assignee: Thomas Dudziak
> Fix For: 3.3.0
>
> Attachments: build.patch, ZOOKEEPER-537.patch
>
>
> This is a problem if you use zookeeper as a dependency in maven because for 
> whatever reason the maven compiler plugin will pick up the java files in the 
> jar and compile them to the output directory. From there they will land in 
> the generated jar file for whatever project happens to depend on zookeeper 
> thus introducing duplicate classes (once in zookeeper.jar, once in the 
> project's artifact).

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

[jira] Commented: (ZOOKEEPER-652) package server and client separately

[Patrick Hunt (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12803787#action_12803787
 ] 

Patrick Hunt commented on ZOOKEEPER-652:


See ZOOKEEPER-537 - 3.3.0 already has the bin/src/jdoc split.

keep in mind that in 3.3.0 we have 4 jars, the legacy jar, and bin/src/jdoc 
jars. If we move fwd on this idea we would have something like 7 jars. ;-)

Also there would be a bit of work to determine/separate the shared code. in 
ZOOKEEPER-233 there was an issue wrt this, in particular you might
end up with 10 jars as a result... Ugh.

With 3.3.0 the bin jar is smaller (no source), not sure how much real benefit 
there is to splitting out the client at that point.


> package server and client separately
> 
>
> Key: ZOOKEEPER-652
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-652
> Project: Zookeeper
>  Issue Type: Improvement
>  Components: build
>Reporter: zhouyanming
>
> is it possible split zookeeper.jar to zookeeper-server.jar and 
> zookeeper-client.jar?
> so app can only use client jar 

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

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

[Patrick Hunt (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-543?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12803793#action_12803793
 ] 

Patrick Hunt commented on ZOOKEEPER-543:


I don't mind adding this, but aren't we testing this already in our tests? If 
not, wouldn't it be better to add these to existing/new test classes
that are more geared to the specific functionality being tested, rather than to 
some example which may change over time? Or is the
idea to point ppl to this "exampletest" class and therefore use it as a 
teaching aid, rather than just a test? Also, putting into say clienttest
class would enable testing under both standalone & quorum (for example). I 
guess my point is, why specifically "exampletest", rather than
just a test? Perhaps I'm just confused by the naming, again, I think the idea 
of adding more tests to cover things we don't already test
is a good idea so don't want to dis-wade you in general.


> 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
>
>
> 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] Created: (ZOOKEEPER-653) hudson failure in LETest

[Patrick Hunt (JIRA)]

hudson failure in LETest


 Key: ZOOKEEPER-653
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-653
 Project: Zookeeper
  Issue Type: Bug
  Components: quorum, server
Reporter: Patrick Hunt
 Fix For: 3.3.0


http://hudson.zones.apache.org/hudson/job/ZooKeeper-trunk/675/testReport/org.apache.zookeeper.test/LETest/testLE/

junit.framework.AssertionFailedError: Threads didn't join
at org.apache.zookeeper.test.LETest.testLE(LETest.java:116)


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

[jira] Commented: (ZOOKEEPER-653) hudson failure in LETest

[Henry Robinson (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-653?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12803839#action_12803839
 ] 

Henry Robinson commented on ZOOKEEPER-653:
--

Could be this: https://issues.apache.org/jira/browse/ZOOKEEPER-569?

> hudson failure in LETest
> 
>
> Key: ZOOKEEPER-653
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-653
> Project: Zookeeper
>  Issue Type: Bug
>  Components: quorum, server
>Reporter: Patrick Hunt
> Fix For: 3.3.0
>
>
> http://hudson.zones.apache.org/hudson/job/ZooKeeper-trunk/675/testReport/org.apache.zookeeper.test/LETest/testLE/
> junit.framework.AssertionFailedError: Threads didn't join
>   at org.apache.zookeeper.test.LETest.testLE(LETest.java:116)

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

[jira] Updated: (ZOOKEEPER-593) java client api does not allow client to access negotiated session timeout

[Patrick Hunt (JIRA)]

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

Patrick Hunt updated ZOOKEEPER-593:
---

Attachment: ZOOKEEPER-593.patch

Updated the java code/docs/tests with a new getSessionTimeout() method.

Also updated the c api documentation (method existed, just no doc, so I added 
doc exclusively)


> java client api does not allow client to access negotiated session timeout
> --
>
> Key: ZOOKEEPER-593
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-593
> Project: Zookeeper
>  Issue Type: Bug
>  Components: java client
>Reporter: Patrick Hunt
>Assignee: Patrick Hunt
> Fix For: 3.3.0
>
> Attachments: ZOOKEEPER-593.patch
>
>
> The java client api does not allow the client to access the negotiated 
> session timeout (c does allow this).
> In some cases the client may not get the requested timeout (server applies a 
> min/max bound) in which case
> the client user code may want to examine the timeout it did receive.

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

[jira] Updated: (ZOOKEEPER-574) the documentation on snapcount in the admin guide has the wrong default

[Patrick Hunt (JIRA)]

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

Patrick Hunt updated ZOOKEEPER-574:
---

Component/s: documentation
   Assignee: Patrick Hunt

> the documentation on snapcount in the admin guide has the wrong default
> ---
>
> Key: ZOOKEEPER-574
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-574
> Project: Zookeeper
>  Issue Type: Bug
>  Components: documentation
>Reporter: Patrick Hunt
>Assignee: Patrick Hunt
>Priority: Minor
> Fix For: 3.3.0
>
> Attachments: ZOOKEEPER-574.patch
>
>
> I believe it's 100k, not 10k
> ---
> snapCount
> (Java system property: zookeeper.snapCount)
> Clients can submit requests faster than ZooKeeper can process them, 
> especially if there are a lot of clients. To prevent ZooKeeper from running 
> out of memory due to queued requests, ZooKeeper will throttle clients so that 
> there is no more than globalOutstandingLimit outstanding requests in the 
> system. The default limit is 1,000.ZooKeeper logs transactions to a 
> transaction log. After snapCount transactions are written to a log file a 
> snapshot is started and a new transaction log file is started. The default 
> snapCount is 10,000.

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

[jira] Updated: (ZOOKEEPER-574) the documentation on snapcount in the admin guide has the wrong default

[Patrick Hunt (JIRA)]

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

Patrick Hunt updated ZOOKEEPER-574:
---

Attachment: ZOOKEEPER-574.patch

fixed documentation with correct default for snapcount

also fixed what looked like a typo in the docs - seems some text from another 
parameter was incorrectly
copied for this parameter. I think I fixed this by removing the unneccessary 
text (it's copied from another
param in that same document)

> the documentation on snapcount in the admin guide has the wrong default
> ---
>
> Key: ZOOKEEPER-574
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-574
> Project: Zookeeper
>  Issue Type: Bug
>  Components: documentation
>Reporter: Patrick Hunt
>Priority: Minor
> Fix For: 3.3.0
>
> Attachments: ZOOKEEPER-574.patch
>
>
> I believe it's 100k, not 10k
> ---
> snapCount
> (Java system property: zookeeper.snapCount)
> Clients can submit requests faster than ZooKeeper can process them, 
> especially if there are a lot of clients. To prevent ZooKeeper from running 
> out of memory due to queued requests, ZooKeeper will throttle clients so that 
> there is no more than globalOutstandingLimit outstanding requests in the 
> system. The default limit is 1,000.ZooKeeper logs transactions to a 
> transaction log. After snapCount transactions are written to a log file a 
> snapshot is started and a new transaction log file is started. The default 
> snapCount is 10,000.

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

[jira] Updated: (ZOOKEEPER-574) the documentation on snapcount in the admin guide has the wrong default

[Patrick Hunt (JIRA)]

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

Patrick Hunt updated ZOOKEEPER-574:
---

Status: Patch Available  (was: Open)

> the documentation on snapcount in the admin guide has the wrong default
> ---
>
> Key: ZOOKEEPER-574
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-574
> Project: Zookeeper
>  Issue Type: Bug
>  Components: documentation
>Reporter: Patrick Hunt
>Assignee: Patrick Hunt
>Priority: Minor
> Fix For: 3.3.0
>
> Attachments: ZOOKEEPER-574.patch
>
>
> I believe it's 100k, not 10k
> ---
> snapCount
> (Java system property: zookeeper.snapCount)
> Clients can submit requests faster than ZooKeeper can process them, 
> especially if there are a lot of clients. To prevent ZooKeeper from running 
> out of memory due to queued requests, ZooKeeper will throttle clients so that 
> there is no more than globalOutstandingLimit outstanding requests in the 
> system. The default limit is 1,000.ZooKeeper logs transactions to a 
> transaction log. After snapCount transactions are written to a log file a 
> snapshot is started and a new transaction log file is started. The default 
> snapCount is 10,000.

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

[jira] Updated: (ZOOKEEPER-593) java client api does not allow client to access negotiated session timeout

[Patrick Hunt (JIRA)]

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

Patrick Hunt updated ZOOKEEPER-593:
---

Status: Patch Available  (was: Open)

> java client api does not allow client to access negotiated session timeout
> --
>
> Key: ZOOKEEPER-593
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-593
> Project: Zookeeper
>  Issue Type: Bug
>  Components: java client
>Reporter: Patrick Hunt
>Assignee: Patrick Hunt
> Fix For: 3.3.0
>
> Attachments: ZOOKEEPER-593.patch
>
>
> The java client api does not allow the client to access the negotiated 
> session timeout (c does allow this).
> In some cases the client may not get the requested timeout (server applies a 
> min/max bound) in which case
> the client user code may want to examine the timeout it did receive.

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

[jira] Created: (ZOOKEEPER-654) Tests should not rely on CONSOLE appender being present

[Henry Robinson (JIRA)]

Tests should not rely on CONSOLE appender being present
---

 Key: ZOOKEEPER-654
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-654
 Project: Zookeeper
  Issue Type: Bug
Affects Versions: 3.2.1
Reporter: Henry Robinson
Priority: Minor


Tests have been failing for us in an environment where we removed the CONSOLE 
appender from log4j. This breaks a couple of tests in QuorumPeerMainTest at 
least.

I have fixed in our builds by replacing CONSOLE with ROLLINGFILE (which we are 
using) for the time being, but messing with the log config shouldn't break 
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-654) Tests should not rely on CONSOLE appender being present

[Patrick Hunt (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12803945#action_12803945
 ] 

Patrick Hunt commented on ZOOKEEPER-654:


it's difficult to test this particular functionality (ie verifying we log 
something in certain cases) without this approach. 

Are you saying we should have a dedicated log4j configuration file as part of 
test, rather than relying on the one in conf?
That would be fine w/me.


> Tests should not rely on CONSOLE appender being present
> ---
>
> Key: ZOOKEEPER-654
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-654
> Project: Zookeeper
>  Issue Type: Bug
>Affects Versions: 3.2.1
>Reporter: Henry Robinson
>Priority: Minor
>
> Tests have been failing for us in an environment where we removed the CONSOLE 
> appender from log4j. This breaks a couple of tests in QuorumPeerMainTest at 
> least.
> I have fixed in our builds by replacing CONSOLE with ROLLINGFILE (which we 
> are using) for the time being, but messing with the log config shouldn't 
> break 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-654) Tests should not rely on CONSOLE appender being present

[Henry Robinson (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12803948#action_12803948
 ] 

Henry Robinson commented on ZOOKEEPER-654:
--

It seems like the code is retrieving a Layout object for log4j which it uses to 
format output to a custom appender. Is there a way of programmatically creating 
a Layout that will do the same thing? 

Something like this:

Layout layout = new SimpleLayout();

passes tests for me.

It depends, is the idea that we test that something is logged under the default 
log4j layout? Or that it gets logged at all (and using any layout that prints 
out messages will do)?



> Tests should not rely on CONSOLE appender being present
> ---
>
> Key: ZOOKEEPER-654
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-654
> Project: Zookeeper
>  Issue Type: Bug
>Affects Versions: 3.2.1
>Reporter: Henry Robinson
>Priority: Minor
>
> Tests have been failing for us in an environment where we removed the CONSOLE 
> appender from log4j. This breaks a couple of tests in QuorumPeerMainTest at 
> least.
> I have fixed in our builds by replacing CONSOLE with ROLLINGFILE (which we 
> are using) for the time being, but messing with the log config shouldn't 
> break 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-654) Tests should not rely on CONSOLE appender being present

[Patrick Hunt (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12803950#action_12803950
 ] 

Patrick Hunt commented on ZOOKEEPER-654:


"logged at all" should be sufficient, if that works great.

regardless we should also have a dedicated log4j config file to keep any 
changes in conf from effecting the tests and their output.


> Tests should not rely on CONSOLE appender being present
> ---
>
> Key: ZOOKEEPER-654
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-654
> Project: Zookeeper
>  Issue Type: Bug
>Affects Versions: 3.2.1
>Reporter: Henry Robinson
>Priority: Minor
>
> Tests have been failing for us in an environment where we removed the CONSOLE 
> appender from log4j. This breaks a couple of tests in QuorumPeerMainTest at 
> least.
> I have fixed in our builds by replacing CONSOLE with ROLLINGFILE (which we 
> are using) for the time being, but messing with the log config shouldn't 
> break tests. 

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

[jira] Updated: (ZOOKEEPER-654) Tests should not rely on CONSOLE appender being present

[Patrick Hunt (JIRA)]

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

Patrick Hunt updated ZOOKEEPER-654:
---

Attachment: ZOOKEEPER-495.patch

I updated the code to only output for non-session events. session event's don't 
have paths (zero len str)

No tests as the current tests were causing this error to be output, I verified 
that the log is not being output in this case.

> Tests should not rely on CONSOLE appender being present
> ---
>
> Key: ZOOKEEPER-654
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-654
> Project: Zookeeper
>  Issue Type: Bug
>Affects Versions: 3.2.1
>Reporter: Henry Robinson
>Priority: Minor
> Attachments: ZOOKEEPER-495.patch
>
>
> Tests have been failing for us in an environment where we removed the CONSOLE 
> appender from log4j. This breaks a couple of tests in QuorumPeerMainTest at 
> least.
> I have fixed in our builds by replacing CONSOLE with ROLLINGFILE (which we 
> are using) for the time being, but messing with the log config shouldn't 
> break tests. 

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

[jira] Updated: (ZOOKEEPER-495) c client logs an invalid error when zookeeper_init is called with chroot

[Patrick Hunt (JIRA)]

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

Patrick Hunt updated ZOOKEEPER-495:
---

Attachment: ZOOKEEPER-495.patch

I updated the code to only output for non-session events. session event's don't 
have paths (zero len str)

No tests as the current tests were causing this error to be output, I verified 
that the log is not being output in this case.

> c client logs an invalid error when zookeeper_init is called with chroot
> 
>
> Key: ZOOKEEPER-495
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-495
> Project: Zookeeper
>  Issue Type: Bug
>  Components: c client
>Affects Versions: 3.2.0
>Reporter: Michi Mutsuzaki
>Priority: Minor
> Fix For: 3.3.0
>
> Attachments: chroot.cc, chroot.log, ZOOKEEPER-495.patch
>
>
> The C client logs this error message when zookeeper_init is called with 
> chroot. 
> 2009-08-03 18:14:29,130:6624(0x5e66e950):zoo_er...@sub_string@730: server 
> path  does not include chroot path /chroot
> I'll attach a simple program to reproduce this.
> Thanks!
> --Michi

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

[jira] Updated: (ZOOKEEPER-654) Tests should not rely on CONSOLE appender being present

[Patrick Hunt (JIRA)]

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

Patrick Hunt updated ZOOKEEPER-654:
---

Attachment: (was: ZOOKEEPER-495.patch)

> Tests should not rely on CONSOLE appender being present
> ---
>
> Key: ZOOKEEPER-654
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-654
> Project: Zookeeper
>  Issue Type: Bug
>Affects Versions: 3.2.1
>Reporter: Henry Robinson
>Priority: Minor
>
> Tests have been failing for us in an environment where we removed the CONSOLE 
> appender from log4j. This breaks a couple of tests in QuorumPeerMainTest at 
> least.
> I have fixed in our builds by replacing CONSOLE with ROLLINGFILE (which we 
> are using) for the time being, but messing with the log config shouldn't 
> break tests. 

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

[jira] Updated: (ZOOKEEPER-495) c client logs an invalid error when zookeeper_init is called with chroot

[Patrick Hunt (JIRA)]

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

Patrick Hunt updated ZOOKEEPER-495:
---

Assignee: Patrick Hunt
  Status: Patch Available  (was: Open)

> c client logs an invalid error when zookeeper_init is called with chroot
> 
>
> Key: ZOOKEEPER-495
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-495
> Project: Zookeeper
>  Issue Type: Bug
>  Components: c client
>Affects Versions: 3.2.0
>Reporter: Michi Mutsuzaki
>Assignee: Patrick Hunt
>Priority: Minor
> Fix For: 3.3.0
>
> Attachments: chroot.cc, chroot.log, ZOOKEEPER-495.patch
>
>
> The C client logs this error message when zookeeper_init is called with 
> chroot. 
> 2009-08-03 18:14:29,130:6624(0x5e66e950):zoo_er...@sub_string@730: server 
> path  does not include chroot path /chroot
> I'll attach a simple program to reproduce this.
> Thanks!
> --Michi

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

[jira] Updated: (ZOOKEEPER-654) Tests should not rely on CONSOLE appender being present

[Patrick Hunt (JIRA)]

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

Patrick Hunt updated ZOOKEEPER-654:
---

Comment: was deleted

(was: I updated the code to only output for non-session events. session event's 
don't have paths (zero len str)

No tests as the current tests were causing this error to be output, I verified 
that the log is not being output in this case.)

> Tests should not rely on CONSOLE appender being present
> ---
>
> Key: ZOOKEEPER-654
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-654
> Project: Zookeeper
>  Issue Type: Bug
>Affects Versions: 3.2.1
>Reporter: Henry Robinson
>Priority: Minor
>
> Tests have been failing for us in an environment where we removed the CONSOLE 
> appender from log4j. This breaks a couple of tests in QuorumPeerMainTest at 
> least.
> I have fixed in our builds by replacing CONSOLE with ROLLINGFILE (which we 
> are using) for the time being, but messing with the log config shouldn't 
> break 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-574) the documentation on snapcount in the admin guide has the wrong default

[Mahadev konar (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-574?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12803961#action_12803961
 ] 

Mahadev konar commented on ZOOKEEPER-574:
-

+1 the patch looks good.

> the documentation on snapcount in the admin guide has the wrong default
> ---
>
> Key: ZOOKEEPER-574
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-574
> Project: Zookeeper
>  Issue Type: Bug
>  Components: documentation
>Reporter: Patrick Hunt
>Assignee: Patrick Hunt
>Priority: Minor
> Fix For: 3.3.0
>
> Attachments: ZOOKEEPER-574.patch
>
>
> I believe it's 100k, not 10k
> ---
> snapCount
> (Java system property: zookeeper.snapCount)
> Clients can submit requests faster than ZooKeeper can process them, 
> especially if there are a lot of clients. To prevent ZooKeeper from running 
> out of memory due to queued requests, ZooKeeper will throttle clients so that 
> there is no more than globalOutstandingLimit outstanding requests in the 
> system. The default limit is 1,000.ZooKeeper logs transactions to a 
> transaction log. After snapCount transactions are written to a log file a 
> snapshot is started and a new transaction log file is started. The default 
> snapCount is 10,000.

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

[jira] Updated: (ZOOKEEPER-574) the documentation on snapcount in the admin guide has the wrong default

[Mahadev konar (JIRA)]

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

Mahadev konar updated ZOOKEEPER-574:


  Resolution: Fixed
Hadoop Flags: [Reviewed]
  Status: Resolved  (was: Patch Available)

I just committed this. thanks pat.

> the documentation on snapcount in the admin guide has the wrong default
> ---
>
> Key: ZOOKEEPER-574
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-574
> Project: Zookeeper
>  Issue Type: Bug
>  Components: documentation
>Reporter: Patrick Hunt
>Assignee: Patrick Hunt
>Priority: Minor
> Fix For: 3.3.0
>
> Attachments: ZOOKEEPER-574.patch
>
>
> I believe it's 100k, not 10k
> ---
> snapCount
> (Java system property: zookeeper.snapCount)
> Clients can submit requests faster than ZooKeeper can process them, 
> especially if there are a lot of clients. To prevent ZooKeeper from running 
> out of memory due to queued requests, ZooKeeper will throttle clients so that 
> there is no more than globalOutstandingLimit outstanding requests in the 
> system. The default limit is 1,000.ZooKeeper logs transactions to a 
> transaction log. After snapCount transactions are written to a log file a 
> snapshot is started and a new transaction log file is started. The default 
> snapCount is 10,000.

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