[jira] [Commented] (ZOOKEEPER-1366) Zookeeper should be tolerant of clock adjustments
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13757489#comment-13757489 ] Ted Dunning commented on ZOOKEEPER-1366: Why do you say this? What scenario would cause a breakage? > Zookeeper should be tolerant of clock adjustments > - > > Key: ZOOKEEPER-1366 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1366 > Project: ZooKeeper > Issue Type: Bug >Reporter: Ted Dunning >Assignee: Ted Dunning > Fix For: 3.5.0 > > Attachments: ZOOKEEPER-1366-3.3.3.patch, ZOOKEEPER-1366.patch, > ZOOKEEPER-1366.patch, ZOOKEEPER-1366.patch, ZOOKEEPER-1366.patch, > ZOOKEEPER-1366.patch, ZOOKEEPER-1366.patch, ZOOKEEPER-1366.patch, > zookeeper-3.4.5-ZK1366-SC01.patch > > > If you want to wreak havoc on a ZK based system just do [date -s "+1hour"] > and watch the mayhem as all sessions expire at once. > This shouldn't happen. Zookeeper could easily know handle elapsed times as > elapsed times rather than as differences between absolute times. The > absolute times are subject to adjustment when the clock is set while a timer > is not subject to this problem. In Java, System.currentTimeMillis() gives > you absolute time while System.nanoTime() gives you time based on a timer > from an arbitrary epoch. > I have done this and have been running tests now for some tens of minutes > with no failures. I will set up a test machine to redo the build again on > Ubuntu and post a patch here for discussion. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (ZOOKEEPER-1366) Zookeeper should be tolerant of clock adjustments
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1366?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13757211#comment-13757211 ] Asad Saeed commented on ZOOKEEPER-1366: --- These patches will break Kerberos login. It mixes monotonic and actual time. > Zookeeper should be tolerant of clock adjustments > - > > Key: ZOOKEEPER-1366 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1366 > Project: ZooKeeper > Issue Type: Bug >Reporter: Ted Dunning >Assignee: Ted Dunning > Fix For: 3.5.0 > > Attachments: ZOOKEEPER-1366-3.3.3.patch, ZOOKEEPER-1366.patch, > ZOOKEEPER-1366.patch, ZOOKEEPER-1366.patch, ZOOKEEPER-1366.patch, > ZOOKEEPER-1366.patch, ZOOKEEPER-1366.patch, ZOOKEEPER-1366.patch, > zookeeper-3.4.5-ZK1366-SC01.patch > > > If you want to wreak havoc on a ZK based system just do [date -s "+1hour"] > and watch the mayhem as all sessions expire at once. > This shouldn't happen. Zookeeper could easily know handle elapsed times as > elapsed times rather than as differences between absolute times. The > absolute times are subject to adjustment when the clock is set while a timer > is not subject to this problem. In Java, System.currentTimeMillis() gives > you absolute time while System.nanoTime() gives you time based on a timer > from an arbitrary epoch. > I have done this and have been running tests now for some tens of minutes > with no failures. I will set up a test machine to redo the build again on > Ubuntu and post a patch here for discussion. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (ZOOKEEPER-1670) zookeeper should set a default value for SERVER_JVMFLAGS and CLIENT_JVMFLAGS so that memory usage is controlled
[
https://issues.apache.org/jira/browse/ZOOKEEPER-1670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13757031#comment-13757031
]
Flavio Junqueira commented on ZOOKEEPER-1670:
-
Thanks for the feedback, Pat. I can really go either way, but given that this
has been here for a long time and I have given time for folks to dispute my +1,
I'd rather not revert it unless you argue that this will really break things
for our users. Is it acceptable to you that we keep it and discuss separately
what you think is the best way to deal with it?
> zookeeper should set a default value for SERVER_JVMFLAGS and CLIENT_JVMFLAGS
> so that memory usage is controlled
> ---
>
> Key: ZOOKEEPER-1670
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1670
> Project: ZooKeeper
> Issue Type: Bug
>Affects Versions: 3.4.5
>Reporter: Arpit Gupta
>Assignee: Flavio Junqueira
> Fix For: 3.5.0, 3.4.6
>
> Attachments: ZOOKEEPER-1670.patch, ZOOKEEPER-1670.patch,
> ZOOKEEPER-1670.patch, ZOOKEEPER-1670.patch, ZOOKEEPER-1670.patch
>
>
> We noticed this with jdk 1.6 where if no heap size is set the process takes
> up to 1/4 of mem available on the machine.
> More info
> http://stackoverflow.com/questions/3428251/is-there-a-default-xmx-setting-for-java-1-5
> You can run the following command to see what are the defaults for your
> machine
> {code}
> java -XX:+PrintFlagsFinal -version 2>&1 | grep -i -E
> 'heapsize|permsize|version'
> {code}
> And we noticed on two different class of machines that this was 1/4th of
> total memory on the machine.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (ZOOKEEPER-1670) zookeeper should set a default value for SERVER_JVMFLAGS and CLIENT_JVMFLAGS so that memory usage is controlled
[
https://issues.apache.org/jira/browse/ZOOKEEPER-1670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13756768#comment-13756768
]
Patrick Hunt commented on ZOOKEEPER-1670:
-
Also rather than patching this for specific issues we might want to think about
it more in the large, esp wrt ZOOKEEPER-545. The default collector is really a
poor setting for us at this point. (esp re stop-the-world collections)
> zookeeper should set a default value for SERVER_JVMFLAGS and CLIENT_JVMFLAGS
> so that memory usage is controlled
> ---
>
> Key: ZOOKEEPER-1670
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1670
> Project: ZooKeeper
> Issue Type: Bug
>Affects Versions: 3.4.5
>Reporter: Arpit Gupta
>Assignee: Flavio Junqueira
> Fix For: 3.5.0, 3.4.6
>
> Attachments: ZOOKEEPER-1670.patch, ZOOKEEPER-1670.patch,
> ZOOKEEPER-1670.patch, ZOOKEEPER-1670.patch, ZOOKEEPER-1670.patch
>
>
> We noticed this with jdk 1.6 where if no heap size is set the process takes
> up to 1/4 of mem available on the machine.
> More info
> http://stackoverflow.com/questions/3428251/is-there-a-default-xmx-setting-for-java-1-5
> You can run the following command to see what are the defaults for your
> machine
> {code}
> java -XX:+PrintFlagsFinal -version 2>&1 | grep -i -E
> 'heapsize|permsize|version'
> {code}
> And we noticed on two different class of machines that this was 1/4th of
> total memory on the machine.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Reopened] (ZOOKEEPER-1670) zookeeper should set a default value for SERVER_JVMFLAGS and CLIENT_JVMFLAGS so that memory usage is controlled
[
https://issues.apache.org/jira/browse/ZOOKEEPER-1670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Patrick Hunt reopened ZOOKEEPER-1670:
-
Assignee: Flavio Junqueira (was: Arpit Gupta)
I think we should revert this change:
1) The original defaults were based on the JVM egonomics. To change things as
this patch does, arbitrarily, might cause problems for some folks. If someone
wants a specific value for the heap they should just specify it on the command
line - I'd be a lot more comfortable if we set the heap only when a user
specified a value (it's ok to have specific env settings for this, just
shouldn't have a default).
2) Also many folks are already specifying the heap size using the command line
"SERVER_JVMFLAGS" parameter. This change will now cause potential problems as
the new defaults may override the SERVER_JVMFLAGS settings already in place.
> zookeeper should set a default value for SERVER_JVMFLAGS and CLIENT_JVMFLAGS
> so that memory usage is controlled
> ---
>
> Key: ZOOKEEPER-1670
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1670
> Project: ZooKeeper
> Issue Type: Bug
>Affects Versions: 3.4.5
>Reporter: Arpit Gupta
>Assignee: Flavio Junqueira
> Fix For: 3.5.0, 3.4.6
>
> Attachments: ZOOKEEPER-1670.patch, ZOOKEEPER-1670.patch,
> ZOOKEEPER-1670.patch, ZOOKEEPER-1670.patch, ZOOKEEPER-1670.patch
>
>
> We noticed this with jdk 1.6 where if no heap size is set the process takes
> up to 1/4 of mem available on the machine.
> More info
> http://stackoverflow.com/questions/3428251/is-there-a-default-xmx-setting-for-java-1-5
> You can run the following command to see what are the defaults for your
> machine
> {code}
> java -XX:+PrintFlagsFinal -version 2>&1 | grep -i -E
> 'heapsize|permsize|version'
> {code}
> And we noticed on two different class of machines that this was 1/4th of
> total memory on the machine.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (ZOOKEEPER-1670) zookeeper should set a default value for SERVER_JVMFLAGS and CLIENT_JVMFLAGS so that memory usage is controlled
[
https://issues.apache.org/jira/browse/ZOOKEEPER-1670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13756762#comment-13756762
]
Arpit Gupta commented on ZOOKEEPER-1670:
bq. Also many folks are already specifying the heap size using the command line
"SERVER_JVMFLAGS" parameter. This change will now cause potential problems as
the new defaults may override the SERVER_JVMFLAGS settings already in place.
I dont think this is true as SERVER_JVMFLAGS is at the end. So if you were
specifying the heap size using SERVER_JVMFLAGS it should still be applied as
the last heap size setting is what will be the picked up.
> zookeeper should set a default value for SERVER_JVMFLAGS and CLIENT_JVMFLAGS
> so that memory usage is controlled
> ---
>
> Key: ZOOKEEPER-1670
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1670
> Project: ZooKeeper
> Issue Type: Bug
>Affects Versions: 3.4.5
>Reporter: Arpit Gupta
>Assignee: Flavio Junqueira
> Fix For: 3.5.0, 3.4.6
>
> Attachments: ZOOKEEPER-1670.patch, ZOOKEEPER-1670.patch,
> ZOOKEEPER-1670.patch, ZOOKEEPER-1670.patch, ZOOKEEPER-1670.patch
>
>
> We noticed this with jdk 1.6 where if no heap size is set the process takes
> up to 1/4 of mem available on the machine.
> More info
> http://stackoverflow.com/questions/3428251/is-there-a-default-xmx-setting-for-java-1-5
> You can run the following command to see what are the defaults for your
> machine
> {code}
> java -XX:+PrintFlagsFinal -version 2>&1 | grep -i -E
> 'heapsize|permsize|version'
> {code}
> And we noticed on two different class of machines that this was 1/4th of
> total memory on the machine.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (ZOOKEEPER-1462) Read-only server does not initialize database properly
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13756695#comment-13756695 ] Germán Blanco commented on ZOOKEEPER-1462: -- I have been able to reproduce this problem only for Observers. The reason seems to be related with the different handling in QuorumPeer.run ... sorry but this is as far as I got for now. Unfortunately the patch doesn't seem to work for me. > Read-only server does not initialize database properly > -- > > Key: ZOOKEEPER-1462 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1462 > Project: ZooKeeper > Issue Type: Bug > Components: server >Affects Versions: 3.4.3 >Reporter: Thawan Kooburat >Assignee: Thawan Kooburat >Priority: Critical > Fix For: 3.4.6 > > Attachments: ZOOKEEPER-1462.patch > > > Brief Description: > When a participant or observer get partitioned and restart as Read-only > server. ZkDb doesn't get reinitialized. This causes the RO server to drop any > incoming request with zxid > 0 > Error message: > Refusing session request for client /xx.xx.xx.xx:39875 > as it has seen zxid 0x2e00405fd9 our last zxid is 0x0 client must try another > server > Steps to reproduce: > Start an RO-enabled observer connecting to an ensemble. Kill the ensemble and > wait until the observer restart in RO mode. Zxid of this observer should be 0. > Description: > Before a server transition into LOOKING state, its database get closed as > part of shutdown sequence. The database of leader, follower and observer get > initialized as a side effect of participating in leader election protocol. > (eg. observer will call registerWithLeader() and call getLastLoggedZxid() > which initialize the db if not already). > However, RO server does not participate in this protocol so its DB doesn't > get initialized properly > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (ZOOKEEPER-1557) jenkins jdk7 test failure in testBadSaslAuthNotifiesWatch
[
https://issues.apache.org/jira/browse/ZOOKEEPER-1557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13756522#comment-13756522
]
Flavio Junqueira commented on ZOOKEEPER-1557:
-
I checked the zookeeper-trunk-jdk7 build and it hasn't run since June, which is
strange. Before June, the builds that failed were due to this test:
{noformat}
org.apache.zookeeper.server.TruncateCorruptionTest.testTransactionLogCorruption
{noformat}
I don't think we have observed this problem since the last comments from
[~phunt], [~mahadev], and [~ekoontz] late last year, so I wonder if this is
still an issue. I don't want to hold 3.4.6 because of this issue, so if there
is no reason or interest in pursuing it further, I'd like to push it to 3.5.0
or simply resolve it for now. This issue is not blocking 3.4.6 quite yet, but
I'm trying to get to a resolution for all issues marked for 3.4.6.
> jenkins jdk7 test failure in testBadSaslAuthNotifiesWatch
> -
>
> Key: ZOOKEEPER-1557
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1557
> Project: ZooKeeper
> Issue Type: Bug
> Components: server
>Affects Versions: 3.5.0, 3.4.5
>Reporter: Patrick Hunt
>Assignee: Eugene Koontz
> Fix For: 3.5.0, 3.4.6
>
> Attachments: jstack.out, SaslAuthFailTest.log, ZOOKEEPER-1557.patch
>
>
> Failure of testBadSaslAuthNotifiesWatch on the jenkins jdk7 job:
> https://builds.apache.org/job/ZooKeeper-trunk-jdk7/407/
> haven't seen this before.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (ZOOKEEPER-1713) wrong time calculation in zkfuse.cc
[
https://issues.apache.org/jira/browse/ZOOKEEPER-1713?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13756515#comment-13756515
]
Hudson commented on ZOOKEEPER-1713:
---
SUCCESS: Integrated in ZooKeeper-trunk #2043 (See
[https://builds.apache.org/job/ZooKeeper-trunk/2043/])
ZOOKEEPER-1713. wrong time calculation in zkfuse.cc (german via fpj) (fpj:
http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1519511)
* /zookeeper/trunk/CHANGES.txt
* /zookeeper/trunk/src/contrib/zkfuse/src/zkfuse.cc
> wrong time calculation in zkfuse.cc
> ---
>
> Key: ZOOKEEPER-1713
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1713
> Project: ZooKeeper
> Issue Type: Bug
>Affects Versions: 3.4.5
> Environment: Linux
>Reporter: Germán Blanco
>Assignee: Germán Blanco
>Priority: Trivial
> Fix For: 3.5.0, 3.4.6
>
> Attachments: ZOOKEEPER-1713.patch
>
>
> A colleague of mine has spotted this error in time calculation in the code in
> zkfuse.cc lines 81 to 85:
> inline
> uint64_t nanosecsToMillisecs(uint64_t nanosecs)
> {
> return nanosecs * 100;
> }
> I am not sure how this method is used, but for sure it will make something
> wrong happen if it is.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (ZOOKEEPER-1379) 'printwatches, redo, history and connect '. client commands always print usage. This is not necessary
[
https://issues.apache.org/jira/browse/ZOOKEEPER-1379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13756514#comment-13756514
]
Hudson commented on ZOOKEEPER-1379:
---
SUCCESS: Integrated in ZooKeeper-trunk #2043 (See
[https://builds.apache.org/job/ZooKeeper-trunk/2043/])
ZOOKEEPER-1379. 'printwatches, redo, history and connect '. client commands
always print usage. This is not necessary (edward via fpj) (fpj:
http://svn.apache.org/viewcvs.cgi/?root=Apache-SVN&view=rev&rev=1519515)
* /zookeeper/trunk/CHANGES.txt
* /zookeeper/trunk/src/java/main/org/apache/zookeeper/ZooKeeperMain.java
* /zookeeper/trunk/src/java/test/org/apache/zookeeper/ZooKeeperTest.java
> 'printwatches, redo, history and connect '. client commands always print
> usage. This is not necessary
> -
>
> Key: ZOOKEEPER-1379
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1379
> Project: ZooKeeper
> Issue Type: Bug
> Components: java client
>Affects Versions: 3.4.0
>Reporter: kavita sharma
>Assignee: Edward Ribeiro
>Priority: Minor
> Fix For: 3.5.0, 3.4.6
>
> Attachments: ZOOKEEPER-1379.2.patch, ZOOKEEPER-1379.3.patch,
> ZOOKEEPER-1379.4.patch, ZOOKEEPER-1379.branch-3.4.patch, ZOOKEEPER-1379.patch
>
>
> while executing the commands:
> 'printwatches, redo, history and connect usage is getting print
> .basically we are printing usage if user has entered the command
> wrong but in these commands case every time usage is getting print.
> eg
> {noformat}
> [zk: localhost:2181(CONNECTED) 0] printwatches
> printwatches is on
> ZooKeeper -server host:port cmd args
> connect host:port
> get path [watch]
> ls path [watch]
> set path data [version]
> delquota [-n|-b] path
> quit
> printwatches on|off
> create [-s] [-e] path data acl
> stat path [watch]
> close
> ls2 path [watch]
> history
> listquota path
> setAcl path acl
> getAcl path
> sync path
> redo cmdno
> addauth scheme auth
> delete path [version]
> setquota -n|-b val path
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (ZOOKEEPER-1603) StaticHostProviderTest testUpdateClientMigrateOrNot hangs
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1603?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Flavio Junqueira updated ZOOKEEPER-1603: Attachment: ZOOKEEPER-1603-b3.4.patch Note that this patch is only for b3.4. > StaticHostProviderTest testUpdateClientMigrateOrNot hangs > - > > Key: ZOOKEEPER-1603 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1603 > Project: ZooKeeper > Issue Type: Bug > Components: tests >Affects Versions: 3.5.0 >Reporter: Patrick Hunt >Assignee: Flavio Junqueira >Priority: Blocker > Fix For: 3.5.0, 3.4.6 > > Attachments: ZOOKEEPER-1603-b3.4.patch, ZOOKEEPER-1603-ver1.patch, > ZOOKEEPER-1603-ver2.patch, ZOOKEEPER-1603-ver3.patch > > > StaticHostProviderTest method testUpdateClientMigrateOrNot hangs forever. > On my laptop getHostName for 10.10.10.* takes 5+ seconds per call. As a > result this method effectively runs forever. > Every time I run this test it hangs. Consistent. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (ZOOKEEPER-1603) StaticHostProviderTest testUpdateClientMigrateOrNot hangs
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1603?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Flavio Junqueira updated ZOOKEEPER-1603: Fix Version/s: 3.4.6 > StaticHostProviderTest testUpdateClientMigrateOrNot hangs > - > > Key: ZOOKEEPER-1603 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1603 > Project: ZooKeeper > Issue Type: Bug > Components: tests >Affects Versions: 3.5.0 >Reporter: Patrick Hunt >Assignee: Flavio Junqueira >Priority: Blocker > Fix For: 3.5.0, 3.4.6 > > Attachments: ZOOKEEPER-1603-ver1.patch, ZOOKEEPER-1603-ver2.patch, > ZOOKEEPER-1603-ver3.patch > > > StaticHostProviderTest method testUpdateClientMigrateOrNot hangs forever. > On my laptop getHostName for 10.10.10.* takes 5+ seconds per call. As a > result this method effectively runs forever. > Every time I run this test it hangs. Consistent. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Reopened] (ZOOKEEPER-1603) StaticHostProviderTest testUpdateClientMigrateOrNot hangs
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1603?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Flavio Junqueira reopened ZOOKEEPER-1603: - Assignee: Flavio Junqueira (was: Alexander Shraer) Under some networks, StaticHostProviderTest fails in the 3.4 branch. I have created a version of the 3.5.0 for the 3.4 branch and I'll be uploading it shortly. I would really appreciate if someone could review it shortly. > StaticHostProviderTest testUpdateClientMigrateOrNot hangs > - > > Key: ZOOKEEPER-1603 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1603 > Project: ZooKeeper > Issue Type: Bug > Components: tests >Affects Versions: 3.5.0 >Reporter: Patrick Hunt >Assignee: Flavio Junqueira >Priority: Blocker > Fix For: 3.5.0 > > Attachments: ZOOKEEPER-1603-ver1.patch, ZOOKEEPER-1603-ver2.patch, > ZOOKEEPER-1603-ver3.patch > > > StaticHostProviderTest method testUpdateClientMigrateOrNot hangs forever. > On my laptop getHostName for 10.10.10.* takes 5+ seconds per call. As a > result this method effectively runs forever. > Every time I run this test it hangs. Consistent. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
ZooKeeper-trunk-solaris - Build # 659 - Still Failing
See https://builds.apache.org/job/ZooKeeper-trunk-solaris/659/ ### ## LAST 60 LINES OF THE CONSOLE ### Started by timer Building remotely on solaris1 in workspace /export/home/hudson/hudson-slave/workspace/ZooKeeper-trunk-solaris FATAL: hudson.remoting.RequestAbortedException: hudson.remoting.Channel$OrderlyShutdown hudson.remoting.RequestAbortedException: hudson.remoting.RequestAbortedException: hudson.remoting.Channel$OrderlyShutdown at hudson.remoting.RequestAbortedException.wrapForRethrow(RequestAbortedException.java:41) at hudson.remoting.RequestAbortedException.wrapForRethrow(RequestAbortedException.java:34) at hudson.remoting.Request.call(Request.java:174) at hudson.remoting.Channel.call(Channel.java:714) at hudson.EnvVars.getRemote(EnvVars.java:212) at hudson.model.Computer.getEnvironment(Computer.java:909) at jenkins.model.CoreEnvironmentContributor.buildEnvironmentFor(CoreEnvironmentContributor.java:40) at hudson.model.Job.getEnvironment(Job.java:374) at hudson.model.AbstractProject.getEnvironment(AbstractProject.java:353) at hudson.model.Run.getEnvironment(Run.java:2111) at hudson.model.AbstractBuild.getEnvironment(AbstractBuild.java:911) at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:776) at hudson.model.AbstractProject.checkout(AbstractProject.java:1408) at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:657) at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:88) at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:562) at hudson.model.Run.execute(Run.java:1603) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:247) Caused by: hudson.remoting.RequestAbortedException: hudson.remoting.Channel$OrderlyShutdown at hudson.remoting.Request.abort(Request.java:299) at hudson.remoting.Channel.terminate(Channel.java:774) at hudson.remoting.Channel$CloseCommand.execute(Channel.java:919) at hudson.remoting.Channel$2.handle(Channel.java:461) at hudson.remoting.SynchronousCommandTransport$ReaderThread.run(SynchronousCommandTransport.java:60) Caused by: hudson.remoting.Channel$OrderlyShutdown ... 3 more Caused by: Command close created at at hudson.remoting.Command.(Command.java:56) at hudson.remoting.Channel$CloseCommand.(Channel.java:913) at hudson.remoting.Channel$CloseCommand.(Channel.java:911) at hudson.remoting.Channel.close(Channel.java:994) at hudson.remoting.Channel.close(Channel.java:977) at hudson.remoting.Channel$CloseCommand.execute(Channel.java:918) ... 2 more ### ## FAILED TESTS (if any) ## No tests ran.
[jira] [Commented] (ZOOKEEPER-1657) Increased CPU usage by unnecessary SASL checks
[
https://issues.apache.org/jira/browse/ZOOKEEPER-1657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13756435#comment-13756435
]
Hadoop QA commented on ZOOKEEPER-1657:
--
+1 overall. Here are the results of testing the latest attachment
http://issues.apache.org/jira/secure/attachment/12601126/ZOOKEEPER-1657.patch
against trunk revision 1519515.
+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 (version 1.3.9)
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:
https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1554//testReport/
Findbugs warnings:
https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1554//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html
Console output:
https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1554//console
This message is automatically generated.
> Increased CPU usage by unnecessary SASL checks
> --
>
> Key: ZOOKEEPER-1657
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1657
> Project: ZooKeeper
> Issue Type: Bug
> Components: java client
>Affects Versions: 3.4.5
>Reporter: Gunnar Wagenknecht
>Assignee: Philip K. Warren
> Labels: performance
> Fix For: 3.5.0, 3.4.6
>
> Attachments: ZOOKEEPER-1657.patch, ZOOKEEPER-1657.patch,
> ZOOKEEPER-1657.patch, ZOOKEEPER-1657.patch, ZOOKEEPER-1657.patch,
> zookeeper-hotspot-gone.png, zookeeper-hotspot.png
>
>
> I did some profiling in one of our Java environments and found an interesting
> footprint in ZooKeeper. The SASL support seems to trigger a lot times on the
> client although it's not even in use.
> Is there a switch to disable SASL completely?
> The attached screenshot shows a 10-minute profiling session on one of our
> production Jetty servers. The Jetty server handles ~1k web requests per
> minute. The average response time per web request is a few milli seconds. The
> profiling was performed on a machine running for >24h.
> We noticed a significant CPU increase on our servers when deploying an update
> from ZooKeeper 3.3.2 to ZooKeeper 3.4.5. Thus, we started investigating. The
> screenshot shows that only 32% CPU time are spent in Jetty. In contrast, 65%
> are spend in ZooKeeper.
> A few notes/thoughts:
> * {{ClientCnxn$SendThread.clientTunneledAuthenticationInProgress}} seems to
> be the culprit
> * {{javax.security.auth.login.Configuration.getConfiguration}} seems to be
> called very often?
> * There is quite a bit reflection involved in
> {{java.security.AccessController.doPrivileged}}
> * No security manager is active in the JVM: I tend to place an if-check in
> the code before calling {{AccessController.doPrivileged}}. When no SM is
> installed, the runnable can be called directly which safes cycles.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
Success: ZOOKEEPER-1657 PreCommit Build #1554
Jira: https://issues.apache.org/jira/browse/ZOOKEEPER-1657 Build: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1554/ ### ## LAST 60 LINES OF THE CONSOLE ### [...truncated 212286 lines...] [exec] BUILD SUCCESSFUL [exec] Total time: 0 seconds [exec] [exec] [exec] [exec] [exec] +1 overall. Here are the results of testing the latest attachment [exec] http://issues.apache.org/jira/secure/attachment/12601126/ZOOKEEPER-1657.patch [exec] against trunk revision 1519515. [exec] [exec] +1 @author. The patch does not contain any @author tags. [exec] [exec] +1 tests included. The patch appears to include 3 new or modified tests. [exec] [exec] +1 javadoc. The javadoc tool did not generate any warning messages. [exec] [exec] +1 javac. The applied patch does not increase the total number of javac compiler warnings. [exec] [exec] +1 findbugs. The patch does not introduce any new Findbugs (version 1.3.9) warnings. [exec] [exec] +1 release audit. The applied patch does not increase the total number of release audit warnings. [exec] [exec] +1 core tests. The patch passed core unit tests. [exec] [exec] +1 contrib tests. The patch passed contrib unit tests. [exec] [exec] Test results: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1554//testReport/ [exec] Findbugs warnings: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1554//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html [exec] Console output: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/1554//console [exec] [exec] This message is automatically generated. [exec] [exec] [exec] == [exec] == [exec] Adding comment to Jira. [exec] == [exec] == [exec] [exec] [exec] Comment added. [exec] d5201f860b1d9aa47c588255d7769cc02f5f6d44 logged out [exec] [exec] [exec] == [exec] == [exec] Finished build. [exec] == [exec] == [exec] [exec] BUILD SUCCESSFUL Total time: 30 minutes 57 seconds Archiving artifacts Recording test results Description set: ZOOKEEPER-1657 Email was triggered for: Success Sending email for trigger: Success ### ## FAILED TESTS (if any) ## All tests passed
ZooKeeper_branch34_solaris - Build # 637 - Failure
See https://builds.apache.org/job/ZooKeeper_branch34_solaris/637/ ### ## LAST 60 LINES OF THE CONSOLE ### Started by timer Building remotely on solaris1 in workspace /export/home/hudson/hudson-slave/workspace/ZooKeeper_branch34_solaris FATAL: hudson.remoting.RequestAbortedException: hudson.remoting.Channel$OrderlyShutdown hudson.remoting.RequestAbortedException: hudson.remoting.RequestAbortedException: hudson.remoting.Channel$OrderlyShutdown at hudson.remoting.RequestAbortedException.wrapForRethrow(RequestAbortedException.java:41) at hudson.remoting.RequestAbortedException.wrapForRethrow(RequestAbortedException.java:34) at hudson.remoting.Request.call(Request.java:174) at hudson.remoting.Channel.call(Channel.java:714) at hudson.EnvVars.getRemote(EnvVars.java:212) at hudson.model.Computer.getEnvironment(Computer.java:909) at jenkins.model.CoreEnvironmentContributor.buildEnvironmentFor(CoreEnvironmentContributor.java:40) at hudson.model.Job.getEnvironment(Job.java:374) at hudson.model.AbstractProject.getEnvironment(AbstractProject.java:353) at hudson.model.Run.getEnvironment(Run.java:2111) at hudson.model.AbstractBuild.getEnvironment(AbstractBuild.java:911) at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:776) at hudson.model.AbstractProject.checkout(AbstractProject.java:1408) at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:657) at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:88) at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:562) at hudson.model.Run.execute(Run.java:1603) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:247) Caused by: hudson.remoting.RequestAbortedException: hudson.remoting.Channel$OrderlyShutdown at hudson.remoting.Request.abort(Request.java:299) at hudson.remoting.Channel.terminate(Channel.java:774) at hudson.remoting.Channel$CloseCommand.execute(Channel.java:919) at hudson.remoting.Channel$2.handle(Channel.java:461) at hudson.remoting.SynchronousCommandTransport$ReaderThread.run(SynchronousCommandTransport.java:60) Caused by: hudson.remoting.Channel$OrderlyShutdown ... 3 more Caused by: Command close created at at hudson.remoting.Command.(Command.java:56) at hudson.remoting.Channel$CloseCommand.(Channel.java:913) at hudson.remoting.Channel$CloseCommand.(Channel.java:911) at hudson.remoting.Channel.close(Channel.java:994) at hudson.remoting.Channel.close(Channel.java:977) at hudson.remoting.Channel$CloseCommand.execute(Channel.java:918) ... 2 more ### ## FAILED TESTS (if any) ## No tests ran.
[jira] [Updated] (ZOOKEEPER-1657) Increased CPU usage by unnecessary SASL checks
[
https://issues.apache.org/jira/browse/ZOOKEEPER-1657?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Flavio Junqueira updated ZOOKEEPER-1657:
Attachment: ZOOKEEPER-1657.patch
> Increased CPU usage by unnecessary SASL checks
> --
>
> Key: ZOOKEEPER-1657
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1657
> Project: ZooKeeper
> Issue Type: Bug
> Components: java client
>Affects Versions: 3.4.5
>Reporter: Gunnar Wagenknecht
>Assignee: Philip K. Warren
> Labels: performance
> Fix For: 3.5.0, 3.4.6
>
> Attachments: ZOOKEEPER-1657.patch, ZOOKEEPER-1657.patch,
> ZOOKEEPER-1657.patch, ZOOKEEPER-1657.patch, ZOOKEEPER-1657.patch,
> zookeeper-hotspot-gone.png, zookeeper-hotspot.png
>
>
> I did some profiling in one of our Java environments and found an interesting
> footprint in ZooKeeper. The SASL support seems to trigger a lot times on the
> client although it's not even in use.
> Is there a switch to disable SASL completely?
> The attached screenshot shows a 10-minute profiling session on one of our
> production Jetty servers. The Jetty server handles ~1k web requests per
> minute. The average response time per web request is a few milli seconds. The
> profiling was performed on a machine running for >24h.
> We noticed a significant CPU increase on our servers when deploying an update
> from ZooKeeper 3.3.2 to ZooKeeper 3.4.5. Thus, we started investigating. The
> screenshot shows that only 32% CPU time are spent in Jetty. In contrast, 65%
> are spend in ZooKeeper.
> A few notes/thoughts:
> * {{ClientCnxn$SendThread.clientTunneledAuthenticationInProgress}} seems to
> be the culprit
> * {{javax.security.auth.login.Configuration.getConfiguration}} seems to be
> called very often?
> * There is quite a bit reflection involved in
> {{java.security.AccessController.doPrivileged}}
> * No security manager is active in the JVM: I tend to place an if-check in
> the code before calling {{AccessController.doPrivileged}}. When no SM is
> installed, the runnable can be called directly which safes cycles.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (ZOOKEEPER-1657) Increased CPU usage by unnecessary SASL checks
[
https://issues.apache.org/jira/browse/ZOOKEEPER-1657?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Flavio Junqueira updated ZOOKEEPER-1657:
Assignee: Philip K. Warren
> Increased CPU usage by unnecessary SASL checks
> --
>
> Key: ZOOKEEPER-1657
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1657
> Project: ZooKeeper
> Issue Type: Bug
> Components: java client
>Affects Versions: 3.4.5
>Reporter: Gunnar Wagenknecht
>Assignee: Philip K. Warren
> Labels: performance
> Fix For: 3.5.0, 3.4.6
>
> Attachments: ZOOKEEPER-1657.patch, ZOOKEEPER-1657.patch,
> ZOOKEEPER-1657.patch, ZOOKEEPER-1657.patch, zookeeper-hotspot-gone.png,
> zookeeper-hotspot.png
>
>
> I did some profiling in one of our Java environments and found an interesting
> footprint in ZooKeeper. The SASL support seems to trigger a lot times on the
> client although it's not even in use.
> Is there a switch to disable SASL completely?
> The attached screenshot shows a 10-minute profiling session on one of our
> production Jetty servers. The Jetty server handles ~1k web requests per
> minute. The average response time per web request is a few milli seconds. The
> profiling was performed on a machine running for >24h.
> We noticed a significant CPU increase on our servers when deploying an update
> from ZooKeeper 3.3.2 to ZooKeeper 3.4.5. Thus, we started investigating. The
> screenshot shows that only 32% CPU time are spent in Jetty. In contrast, 65%
> are spend in ZooKeeper.
> A few notes/thoughts:
> * {{ClientCnxn$SendThread.clientTunneledAuthenticationInProgress}} seems to
> be the culprit
> * {{javax.security.auth.login.Configuration.getConfiguration}} seems to be
> called very often?
> * There is quite a bit reflection involved in
> {{java.security.AccessController.doPrivileged}}
> * No security manager is active in the JVM: I tend to place an if-check in
> the code before calling {{AccessController.doPrivileged}}. When no SM is
> installed, the runnable can be called directly which safes cycles.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (ZOOKEEPER-1657) Increased CPU usage by unnecessary SASL checks
[
https://issues.apache.org/jira/browse/ZOOKEEPER-1657?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Flavio Junqueira updated ZOOKEEPER-1657:
Assignee: (was: Eugene Koontz)
> Increased CPU usage by unnecessary SASL checks
> --
>
> Key: ZOOKEEPER-1657
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1657
> Project: ZooKeeper
> Issue Type: Bug
> Components: java client
>Affects Versions: 3.4.5
>Reporter: Gunnar Wagenknecht
> Labels: performance
> Fix For: 3.5.0, 3.4.6
>
> Attachments: ZOOKEEPER-1657.patch, ZOOKEEPER-1657.patch,
> ZOOKEEPER-1657.patch, ZOOKEEPER-1657.patch, zookeeper-hotspot-gone.png,
> zookeeper-hotspot.png
>
>
> I did some profiling in one of our Java environments and found an interesting
> footprint in ZooKeeper. The SASL support seems to trigger a lot times on the
> client although it's not even in use.
> Is there a switch to disable SASL completely?
> The attached screenshot shows a 10-minute profiling session on one of our
> production Jetty servers. The Jetty server handles ~1k web requests per
> minute. The average response time per web request is a few milli seconds. The
> profiling was performed on a machine running for >24h.
> We noticed a significant CPU increase on our servers when deploying an update
> from ZooKeeper 3.3.2 to ZooKeeper 3.4.5. Thus, we started investigating. The
> screenshot shows that only 32% CPU time are spent in Jetty. In contrast, 65%
> are spend in ZooKeeper.
> A few notes/thoughts:
> * {{ClientCnxn$SendThread.clientTunneledAuthenticationInProgress}} seems to
> be the culprit
> * {{javax.security.auth.login.Configuration.getConfiguration}} seems to be
> called very often?
> * There is quite a bit reflection involved in
> {{java.security.AccessController.doPrivileged}}
> * No security manager is active in the JVM: I tend to place an if-check in
> the code before calling {{AccessController.doPrivileged}}. When no SM is
> installed, the runnable can be called directly which safes cycles.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (ZOOKEEPER-1655) Make jline dependency optional in maven pom
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13756402#comment-13756402 ] Flavio Junqueira commented on ZOOKEEPER-1655: - Thanks for the feedback, Thomas. Could you update the patch to upgrade the jline version number, please? If you haven't done it, please make sure it applies to both trunk and 3.4 branch. > Make jline dependency optional in maven pom > --- > > Key: ZOOKEEPER-1655 > URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1655 > Project: ZooKeeper > Issue Type: Bug > Components: build >Affects Versions: 3.4.2 >Reporter: Thomas Weise >Assignee: Thomas Weise > Fix For: 3.5.0, 3.4.6 > > Attachments: ZOOKEEPER-1655.patch > > > Old JLine version used in ZK CLI should not be pulled into downstream > projects. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
