ZooKeeper-trunk-WinVS2008 - Build # 1780 - Still Failing
See https://builds.apache.org/job/ZooKeeper-trunk-WinVS2008/1780/ ### ## LAST 60 LINES OF THE CONSOLE ### [...truncated 108 lines...] [javacc] File SimpleCharStream.java does not exist. Will create one. [javacc] Parser generated successfully. jute: [javac] Compiling 39 source files to f:\hudson\hudson-slave\workspace\ZooKeeper-trunk-WinVS2008\trunk\build\classes compile_jute_uptodate: compile_jute: [mkdir] Created dir: f:\hudson\hudson-slave\workspace\ZooKeeper-trunk-WinVS2008\trunk\src\java\generated [mkdir] Created dir: f:\hudson\hudson-slave\workspace\ZooKeeper-trunk-WinVS2008\trunk\src\c\generated [java] ../../zookeeper.jute Parsed Successfully [java] ../../zookeeper.jute Parsed Successfully [touch] Creating f:\hudson\hudson-slave\workspace\ZooKeeper-trunk-WinVS2008\trunk\src\java\generated\.generated BUILD SUCCESSFUL Total time: 8 seconds [ZooKeeper-trunk-WinVS2008] $ cmd /c call C:\Windows\TEMP\hudson5697231797132787997.bat f:\hudson\hudson-slave\workspace\ZooKeeper-trunk-WinVS2008set ZOOKEEPER_HOME=f:\hudson\hudson-slave\workspace\ZooKeeper-trunk-WinVS2008\trunk f:\hudson\hudson-slave\workspace\ZooKeeper-trunk-WinVS2008msbuild trunk/src/c/zookeeper.sln /p:Configuration=Release Microsoft (R) Build Engine version 4.0.30319.18408 [Microsoft .NET Framework, version 4.0.30319.18444] Copyright (C) Microsoft Corporation. All rights reserved. Building the projects in this solution one at a time. To enable parallel build, please add the /m switch. Build started 4/30/2015 9:23:40 AM. Project f:\hudson\hudson-slave\workspace\ZooKeeper-trunk-WinVS2008\trunk\src\c\zookeeper.sln on node 1 (default targets). ValidateSolutionConfiguration: Building solution configuration Release|Win32. zookeeper: C:\Program Files (x86)\Microsoft Visual Studio 9.0\Common7\IDE\..\..\vc\vcpackages\VCBuild.exe f:\hudson\hudson-slave\workspace\ZooKeeper-trunk-WinVS2008\trunk\src\c\zookeeper.vcproj Release|Win32 cl : Command line warning D9035: option 'Wp64' has been deprecated and will be removed in a future release [f:\hudson\hudson-slave\workspace\ZooKeeper-trunk-WinVS2008\trunk\src\c\zookeeper.sln] .\src\zookeeper.c(43): fatal error C1083: Cannot open include file: 'unistd.h': No such file or directory [f:\hudson\hudson-slave\workspace\ZooKeeper-trunk-WinVS2008\trunk\src\c\zookeeper.sln] Cli: C:\Program Files (x86)\Microsoft Visual Studio 9.0\Common7\IDE\..\..\vc\vcpackages\VCBuild.exe f:\hudson\hudson-slave\workspace\ZooKeeper-trunk-WinVS2008\trunk\src\c\Cli.vcproj Release|Win32 Done Building Project f:\hudson\hudson-slave\workspace\ZooKeeper-trunk-WinVS2008\trunk\src\c\zookeeper.sln (default targets) -- FAILED. Build FAILED. f:\hudson\hudson-slave\workspace\ZooKeeper-trunk-WinVS2008\trunk\src\c\zookeeper.sln (default target) (1) - (zookeeper target) - cl : Command line warning D9035: option 'Wp64' has been deprecated and will be removed in a future release [f:\hudson\hudson-slave\workspace\ZooKeeper-trunk-WinVS2008\trunk\src\c\zookeeper.sln] f:\hudson\hudson-slave\workspace\ZooKeeper-trunk-WinVS2008\trunk\src\c\zookeeper.sln (default target) (1) - (zookeeper target) - .\src\zookeeper.c(43): fatal error C1083: Cannot open include file: 'unistd.h': No such file or directory [f:\hudson\hudson-slave\workspace\ZooKeeper-trunk-WinVS2008\trunk\src\c\zookeeper.sln] 1 Warning(s) 1 Error(s) Time Elapsed 00:00:07.06 f:\hudson\hudson-slave\workspace\ZooKeeper-trunk-WinVS2008exit 1 Build step 'Execute Windows batch command' marked build as failure Email was triggered for: Failure Sending email for trigger: Failure ### ## FAILED TESTS (if any) ## No tests ran.
[jira] [Commented] (ZOOKEEPER-2175) Checksum validation for malformed packets needs to handle.
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14521069#comment-14521069
]
Brahma Reddy Battula commented on ZOOKEEPER-2175:
-
[~cnauroth] ,[~rakeshr] and [~phunt] any suggestions for this..? this is
blocked for HDFS-8161...
Checksum validation for malformed packets needs to handle.
--
Key: ZOOKEEPER-2175
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2175
Project: ZooKeeper
Issue Type: Bug
Reporter: Brahma Reddy Battula
*Session Id from ZK :*
2015-04-15 21:24:54,257 | INFO | CommitProcessor:22 | Established session
0x164cb2b3e4b36ae4 with negotiated timeout 45000 for client
/160.149.0.117:44586 |
org.apache.zookeeper.server.ZooKeeperServer.finishSessionInit(ZooKeeperServer.java:623)
2015-04-15 21:24:54,261 | INFO |
NIOServerCxn.Factory:160-149-0-114/160.149.0.114:24002 | Successfully
authenticated client: authenticationID=hdfs/had...@hadoop.com;
authorizationID=hdfs/had...@hadoop.com. |
org.apache.zookeeper.server.auth.SaslServerCallbackHandler.handleAuthorizeCallback(SaslServerCallbackHandler.java:118)
2015-04-15 21:24:54,261 | INFO |
NIOServerCxn.Factory:160-149-0-114/160.149.0.114:24002 | Setting
authorizedID: hdfs/had...@hadoop.com |
org.apache.zookeeper.server.auth.SaslServerCallbackHandler.handleAuthorizeCallback(SaslServerCallbackHandler.java:134)
2015-04-15 21:24:54,261 | INFO |
NIOServerCxn.Factory:160-149-0-114/160.149.0.114:24002 | adding SASL
authorization for authorizationID: hdfs/had...@hadoop.com |
org.apache.zookeeper.server.ZooKeeperServer.processSasl(ZooKeeperServer.java:1009)
2015-04-15 21:24:54,262 | INFO | ProcessThread(sid:22 cport:-1): | Got
user-level KeeperException when processing
*{color:red}sessionid:0x164cb2b3e4b36ae4{color}* type:create cxid:0x3
zxid:0x20009fafc txntype:-1 reqpath:n/a Error
Path:/hadoop-ha/hacluster/ActiveStandbyElectorLock Error:KeeperErrorCode =
NodeExists for /hadoop-ha/hacluster/ActiveStandbyElectorLock |
org.apache.zookeeper.server.PrepRequestProcessor.pRequest(PrepRequestProcessor.java:648)
*ZKFC Received :* ZK client
2015-04-15 21:24:54,237 | INFO | main-SendThread(160-149-0-114:24002) |
Socket connection established to 160-149-0-114/160.149.0.114:24002,
initiating session |
org.apache.zookeeper.ClientCnxn$SendThread.primeConnection(ClientCnxn.java:854)
2015-04-15 21:24:54,257 | INFO | main-SendThread(160-149-0-114:24002) |
Session establishment complete on server 160-149-0-114/160.149.0.114:24002,
*{color:blue}sessionid = 0x144cb2b3e4b36ae4 {color}* , negotiated timeout =
45000 |
org.apache.zookeeper.ClientCnxn$SendThread.onConnected(ClientCnxn.java:1259)
2015-04-15 21:24:54,260 | INFO | main-EventThread | EventThread shut down |
org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:512)
2015-04-15 21:24:54,262 | INFO | main-EventThread | Session connected. |
org.apache.hadoop.ha.ActiveStandbyElector.processWatchEvent(ActiveStandbyElector.java:547)
2015-04-15 21:24:54,264 | INFO | main-EventThread | Successfully
authenticated to ZooKeeper using SASL. |
org.apache.hadoop.ha.ActiveStandbyElector.processWatchEvent(ActiveStandbyElector.java:573)
one bit corrupted..please check the following for same..
144cb2b3e4b36ae4=101000100110010110010101100100100101100110110101011100100
164cb2b3e4b36ae4=101100100110010110010101100100100101100110110101011100100
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
ZooKeeper-trunk-solaris - Build # 1017 - Still Failing
See https://builds.apache.org/job/ZooKeeper-trunk-solaris/1017/ ### ## LAST 60 LINES OF THE CONSOLE ### Started by timer Building remotely on solaris1 (Solaris) in workspace /export/home/hudson/hudson-slave/workspace/ZooKeeper-trunk-solaris Updating http://svn.apache.org/repos/asf/zookeeper/trunk at revision '2015-04-30T08:31:08.097 +' At revision 1676924 Updating http://svn.apache.org/repos/asf/hadoop/nightly at revision '2015-04-30T08:31:08.097 +' At revision 1676924 no change for http://svn.apache.org/repos/asf/zookeeper/trunk since the previous build no change for http://svn.apache.org/repos/asf/hadoop/nightly since the previous build No emails were triggered. [locks-and-latches] Checking to see if we really have the locks [locks-and-latches] Have all the locks, build can start [ZooKeeper-trunk-solaris] $ /bin/bash /var/tmp/hudson2252432063218077932.sh /var/tmp/hudson2252432063218077932.sh: line 12: ant: command not found Build step 'Execute shell' marked build as failure [locks-and-latches] Releasing all the locks [locks-and-latches] All the locks released Recording test results Email was triggered for: Failure Sending email for trigger: Failure ### ## FAILED TESTS (if any) ## No tests ran.
Re: ASC/SHA1/MD5 data for releases missing since 3.3.2
Thank you for following up on this Chris! I filed a jira to update releases.html: https://issues.apache.org/jira/browse/ZOOKEEPER-2177 On Wed, Apr 29, 2015 at 10:53 PM, Chris Nauroth cnaur...@hortonworks.com wrote: Apache infra replied stating that this is working by design. The hashes and signatures are not propagated to mirrors. Instead, they reside only at apache.org. That makes sense when you consider that a malicious mirror could host bad bits (i.e. containing backdoors) and then just provide a hash that matches that patched binary. Instead, we state that the hashes and signatures come from apache.org. As long as you trust the apache.org domain, you know that those hashes and signatures are trustworthy. A potential improvement would be to update releases.html to provide a hyperlink to the relevant spot in apache.org for hash and signature files. Infra also stated that the .mds file I mentioned for Hadoop is considered non-standard, and therefore not subject to this filtering for the mirrors. --Chris Nauroth On 4/29/15, 3:56 PM, Chris Nauroth cnaur...@hortonworks.com wrote: Thanks, Flavio. I went ahead and filed the infra ticket: https://issues.apache.org/jira/browse/INFRA-9556 --Chris Nauroth On 4/29/15, 3:16 PM, Flavio Junqueira fpjunque...@yahoo.com.INVALID wrote: +1 to checking with infra. -Flavio On 29 Apr 2015, at 23:09, Chris Nauroth cnaur...@hortonworks.com wrote: For the sake of comparison to another Apache project, here is a mirror of Hadoop: http://www.webhostingreviewjam.com/mirror/apache/hadoop/common/hadoop-2. 7 .0 / The checksum information in the .mds file is mirrored, but the signature in the .asc file is not mirrored. For ZooKeeper on that same mirror, both the signature and the checksum are missing: http://www.webhostingreviewjam.com/mirror/apache/zookeeper/zookeeper-3.5 . 0- alpha/ I'm not familiar with the details of the mirroring configuration. Maybe it's worth filing an INFRA ticket? --Chris Nauroth On 4/29/15, 2:47 PM, Flavio Junqueira fpjunque...@yahoo.com.INVALID wrote: But is it expected that the signature files aren't propagated to the mirrors? I'd think that they should be propagated too. -Flavio On 29 Apr 2015, at 19:29, Michi Mutsuzaki mutsuz...@gmail.com wrote: You can find these files here: https://www.apache.org/dist/zookeeper/ I guess these files are not mirrored for security reasons. On Wed, Apr 29, 2015 at 10:49 AM, Flavio Junqueira fpjunque...@yahoo.com.invalid wrote: That's weird, we definitely generate them for the RCs, and I'm quite sure were publishing them: http://people.apache.org/~fpj/zookeeper-3.4.6-candidate-0/ I'm not sure what's going, and Pat Hunt might know about it. I'll see if I can find out more in the meanwhile. -Flavio On Wednesday, April 29, 2015 4:13 PM, ralph tice ralph.t...@gmail.com wrote: Hi, I was surprised to discover that releases haven't been published with MD5/etc signatures since 3.3.2. Is this an intentional change by the project or an oversight? Is there an alternative method of verifying integrity of releases? Thanks, --Ralph
[jira] [Created] (ZOOKEEPER-2177) point to md5/sha1/asc files in releases.html
Michi Mutsuzaki created ZOOKEEPER-2177: -- Summary: point to md5/sha1/asc files in releases.html Key: ZOOKEEPER-2177 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2177 Project: ZooKeeper Issue Type: Task Reporter: Michi Mutsuzaki Priority: Minor these files are not mirrored. we should link to these files in http://zookeeper.apache.org/releases.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ZOOKEEPER-2171) avoid reverse lookups in QuorumCnxManager
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14521312#comment-14521312
]
Rakesh R commented on ZOOKEEPER-2171:
-
Re-attaching the previous patch again to trigger one more build. [~rgs] could
you please change the status to {{PatchAvailable}}, this button is not showing
for me.
avoid reverse lookups in QuorumCnxManager
-
Key: ZOOKEEPER-2171
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2171
Project: ZooKeeper
Issue Type: Bug
Components: quorum
Reporter: Raul Gutierrez Segales
Assignee: Raul Gutierrez Segales
Fix For: 3.5.1, 3.6.0
Attachments: ZOOKEEPER-2171.patch, ZOOKEEPER-2171.patch,
ZOOKEEPER-2171.patch
Apparently, ZOOKEEPER-107 (via a quick git-blame look) introduced a bunch of
getHostName() calls in QCM. Besides the overhead, these can cause problems
when mixed with failing/mis-configured DNS servers.
It would be nice to reduce them, if that doesn't affect operational
correctness.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (ZOOKEEPER-2171) avoid reverse lookups in QuorumCnxManager
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rakesh R updated ZOOKEEPER-2171: Attachment: ZOOKEEPER-2171.patch avoid reverse lookups in QuorumCnxManager - Key: ZOOKEEPER-2171 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2171 Project: ZooKeeper Issue Type: Bug Components: quorum Reporter: Raul Gutierrez Segales Assignee: Raul Gutierrez Segales Fix For: 3.5.1, 3.6.0 Attachments: ZOOKEEPER-2171.patch, ZOOKEEPER-2171.patch, ZOOKEEPER-2171.patch Apparently, ZOOKEEPER-107 (via a quick git-blame look) introduced a bunch of getHostName() calls in QCM. Besides the overhead, these can cause problems when mixed with failing/mis-configured DNS servers. It would be nice to reduce them, if that doesn't affect operational correctness. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ZOOKEEPER-2153) X509 Authentication Documentation
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14521341#comment-14521341 ] Rakesh R commented on ZOOKEEPER-2153: - Thanks [~iandi] for the patch. LGTM +1 X509 Authentication Documentation - Key: ZOOKEEPER-2153 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2153 Project: ZooKeeper Issue Type: Sub-task Reporter: Hongchao Deng Assignee: Ian Dimayuga Attachments: ZOOKEEPER-2153.patch -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ZOOKEEPER-2175) Checksum validation for malformed packets needs to handle.
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14521252#comment-14521252
]
Rakesh R commented on ZOOKEEPER-2175:
-
Thanks [~brahmareddy] for the good analysis. Yes, this is a case of packet
corruption while transferring the packets between client and the connected ZK
server. Here the tricky part is, only one bit of {{session id}} got corrupted.
Following are the suggestions I can think of,
# IIUC packet corruption/malformation would get resolved if we have
wire-encryption in place. ZooKeeper is supporting this feature 3.5.x version
onwards. The major work has been completed and few more to go. Please see
ZOOKEEPER-2120, ZOOKEEPER-2125 jira to watch the progress. I think the issue
reported on 3.4.6 version, it doesn't have wire-encryption feature available.
It would be good to test this scenario(can use Wireshark simulator tool) once
wire-encryption feature is fully implemented : client-to-server and
server-to-server communication.
# Secondly, I feel we could think of providing additional checks by validating
the {{session id}} on every client-server communication.But this won't
completely solve the problem because consider another case where the user data
is getting corrupted.
Checksum validation for malformed packets needs to handle.
--
Key: ZOOKEEPER-2175
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2175
Project: ZooKeeper
Issue Type: Bug
Reporter: Brahma Reddy Battula
*Session Id from ZK :*
2015-04-15 21:24:54,257 | INFO | CommitProcessor:22 | Established session
0x164cb2b3e4b36ae4 with negotiated timeout 45000 for client
/160.149.0.117:44586 |
org.apache.zookeeper.server.ZooKeeperServer.finishSessionInit(ZooKeeperServer.java:623)
2015-04-15 21:24:54,261 | INFO |
NIOServerCxn.Factory:160-149-0-114/160.149.0.114:24002 | Successfully
authenticated client: authenticationID=hdfs/had...@hadoop.com;
authorizationID=hdfs/had...@hadoop.com. |
org.apache.zookeeper.server.auth.SaslServerCallbackHandler.handleAuthorizeCallback(SaslServerCallbackHandler.java:118)
2015-04-15 21:24:54,261 | INFO |
NIOServerCxn.Factory:160-149-0-114/160.149.0.114:24002 | Setting
authorizedID: hdfs/had...@hadoop.com |
org.apache.zookeeper.server.auth.SaslServerCallbackHandler.handleAuthorizeCallback(SaslServerCallbackHandler.java:134)
2015-04-15 21:24:54,261 | INFO |
NIOServerCxn.Factory:160-149-0-114/160.149.0.114:24002 | adding SASL
authorization for authorizationID: hdfs/had...@hadoop.com |
org.apache.zookeeper.server.ZooKeeperServer.processSasl(ZooKeeperServer.java:1009)
2015-04-15 21:24:54,262 | INFO | ProcessThread(sid:22 cport:-1): | Got
user-level KeeperException when processing
*{color:red}sessionid:0x164cb2b3e4b36ae4{color}* type:create cxid:0x3
zxid:0x20009fafc txntype:-1 reqpath:n/a Error
Path:/hadoop-ha/hacluster/ActiveStandbyElectorLock Error:KeeperErrorCode =
NodeExists for /hadoop-ha/hacluster/ActiveStandbyElectorLock |
org.apache.zookeeper.server.PrepRequestProcessor.pRequest(PrepRequestProcessor.java:648)
*ZKFC Received :* ZK client
2015-04-15 21:24:54,237 | INFO | main-SendThread(160-149-0-114:24002) |
Socket connection established to 160-149-0-114/160.149.0.114:24002,
initiating session |
org.apache.zookeeper.ClientCnxn$SendThread.primeConnection(ClientCnxn.java:854)
2015-04-15 21:24:54,257 | INFO | main-SendThread(160-149-0-114:24002) |
Session establishment complete on server 160-149-0-114/160.149.0.114:24002,
*{color:blue}sessionid = 0x144cb2b3e4b36ae4 {color}* , negotiated timeout =
45000 |
org.apache.zookeeper.ClientCnxn$SendThread.onConnected(ClientCnxn.java:1259)
2015-04-15 21:24:54,260 | INFO | main-EventThread | EventThread shut down |
org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:512)
2015-04-15 21:24:54,262 | INFO | main-EventThread | Session connected. |
org.apache.hadoop.ha.ActiveStandbyElector.processWatchEvent(ActiveStandbyElector.java:547)
2015-04-15 21:24:54,264 | INFO | main-EventThread | Successfully
authenticated to ZooKeeper using SASL. |
org.apache.hadoop.ha.ActiveStandbyElector.processWatchEvent(ActiveStandbyElector.java:573)
one bit corrupted..please check the following for same..
144cb2b3e4b36ae4=101000100110010110010101100100100101100110110101011100100
164cb2b3e4b36ae4=101100100110010110010101100100100101100110110101011100100
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (ZOOKEEPER-2153) X509 Authentication Documentation
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14521297#comment-14521297 ] Rakesh R commented on ZOOKEEPER-2153: - [~iandi] would you be interested on raising a task for this and work it on. X509 Authentication Documentation - Key: ZOOKEEPER-2153 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2153 Project: ZooKeeper Issue Type: Sub-task Reporter: Hongchao Deng Assignee: Ian Dimayuga Attachments: ZOOKEEPER-2153.patch -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ZOOKEEPER-2154) NPE in KeeperException
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14521343#comment-14521343 ] Rakesh R commented on ZOOKEEPER-2154: - I could see similar case of packet malformation in another jira ZOOKEEPER-2175, any suggestion to handle these kinda issues? NPE in KeeperException -- Key: ZOOKEEPER-2154 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2154 Project: ZooKeeper Issue Type: Bug Components: java client Affects Versions: 3.4.0 Reporter: surendra singh lilhore Assignee: surendra singh lilhore Attachments: ZOOKEEPER-2154.patch KeeperException should handle exception is code is null... -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ZOOKEEPER-1920) Login thread is not shutdown when close the ClientCnxn
[
https://issues.apache.org/jira/browse/ZOOKEEPER-1920?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14521346#comment-14521346
]
Bob commented on ZOOKEEPER-1920:
[~rakeshr] Thanks for your reply.
{quote}
ZooKeeperSaslClient login object is static and the thread is created only once
for the lifetime of that application(I mean per jvm). It looks like its done
intentionally, isn't it?
{quote}
Ideally static login object will control one login thread in one JVM. I came
across one scenario is like Following:
One application will create one zk client and this will loads class
separately.Here we will run multiple applications continuously in single java
class ( which means single JVM ) where we seen login object getting created for
every application which is not getting closed even we call zk.close .
*Application which will called for every time in single Java Class*
{code}
classLoader = new MyClassloader(new URL[] {});
try {
File file = new File(libPath);
File[] jarsFiles = file.listFiles();
for (File jarFile : jarsFiles) {
LOGGER.info(load jar: {},
jarFile.getAbsolutePath());
classLoader.addJar(jarFile.toURL());
}
} catch (MalformedURLException e) {
e.printStackTrace();
}
servlet = (PretendedServlet)Class.forName(com.zk.PretendedZK,
true, classLoader).newInstance();
servlet.init();
{code}
*Zkclient Threads which we are using same in init*
{code}
public void init() {
if (null == login) {
LOGGER.info(init login.);
login = new PretendedLogin();
login.start();
}
startSendThread();
startEventThread();
}
{code}
Login thread is not shutdown when close the ClientCnxn
--
Key: ZOOKEEPER-1920
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1920
Project: ZooKeeper
Issue Type: Bug
Components: java client
Affects Versions: 3.4.6
Reporter: liuyang
Assignee: Rakesh R
Priority: Minor
A new ZooKeeper client will start three threads, the SendThread, EventThread
and LoginThread. I belive that these threads will be shutdown after call the
zk.close. I test that the SendThread and EventThread will be die, but
LoginThread is still alive. The stack is:
Thread-0 daemon prio=10 tid=0x7ffcf002 nid=0x69c8 waiting on
condition [0x7ffd3cc25000]
java.lang.Thread.State: TIMED_WAITING (sleeping)
at java.lang.Thread.sleep(Native Method)
at org.apache.zookeeper.Login$1.run(Login.java:183)
at java.lang.Thread.run(Thread.java:744)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
ZooKeeper_branch35_jdk7 - Build # 280 - Failure
See https://builds.apache.org/job/ZooKeeper_branch35_jdk7/280/ ### ## LAST 60 LINES OF THE CONSOLE ### [...truncated 371779 lines...] [junit] 2015-04-30 12:00:08,957 [myid:] - INFO [main:FourLetterWordMain@63] - connecting to 127.0.0.1 11221 [junit] 2015-04-30 12:00:08,958 [myid:] - INFO [main:JMXEnv@142] - ensureOnly:[] [junit] 2015-04-30 12:00:08,959 [myid:] - INFO [main:ClientBase@461] - STARTING server [junit] 2015-04-30 12:00:08,959 [myid:] - INFO [main:ClientBase@381] - CREATING server instance 127.0.0.1:11221 [junit] 2015-04-30 12:00:08,960 [myid:] - INFO [main:NIOServerCnxnFactory@673] - Configuring NIO connection handler with 10s sessionless connection timeout, 1 selector thread(s), 8 worker threads, and 64 kB direct buffers. [junit] 2015-04-30 12:00:08,960 [myid:] - INFO [main:NIOServerCnxnFactory@686] - binding to port 0.0.0.0/0.0.0.0:11221 [junit] 2015-04-30 12:00:08,960 [myid:] - INFO [main:ClientBase@356] - STARTING server instance 127.0.0.1:11221 [junit] 2015-04-30 12:00:08,961 [myid:] - INFO [main:ZooKeeperServer@825] - minSessionTimeout set to 6000 [junit] 2015-04-30 12:00:08,961 [myid:] - INFO [main:ZooKeeperServer@834] - maxSessionTimeout set to 6 [junit] 2015-04-30 12:00:08,961 [myid:] - INFO [main:ZooKeeperServer@156] - Created server with tickTime 3000 minSessionTimeout 6000 maxSessionTimeout 6 datadir /jenkins/workspace/ZooKeeper_branch35_jdk7/branch-3.5/build/test/tmp/test1369678936319618476.junit.dir/version-2 snapdir /jenkins/workspace/ZooKeeper_branch35_jdk7/branch-3.5/build/test/tmp/test1369678936319618476.junit.dir/version-2 [junit] 2015-04-30 12:00:08,962 [myid:] - INFO [main:FileSnap@83] - Reading snapshot /jenkins/workspace/ZooKeeper_branch35_jdk7/branch-3.5/build/test/tmp/test1369678936319618476.junit.dir/version-2/snapshot.b [junit] 2015-04-30 12:00:08,965 [myid:] - INFO [main:FileTxnSnapLog@298] - Snapshotting: 0xb to /jenkins/workspace/ZooKeeper_branch35_jdk7/branch-3.5/build/test/tmp/test1369678936319618476.junit.dir/version-2/snapshot.b [junit] 2015-04-30 12:00:08,967 [myid:] - INFO [main:FourLetterWordMain@63] - connecting to 127.0.0.1 11221 [junit] 2015-04-30 12:00:08,968 [myid:] - INFO [NIOServerCxnFactory.AcceptThread:0.0.0.0/0.0.0.0:11221:NIOServerCnxnFactory$AcceptThread@296] - Accepted socket connection from /127.0.0.1:33028 [junit] 2015-04-30 12:00:08,969 [myid:] - INFO [NIOWorkerThread-1:NIOServerCnxn@836] - Processing stat command from /127.0.0.1:33028 [junit] 2015-04-30 12:00:08,969 [myid:] - INFO [NIOWorkerThread-1:NIOServerCnxn$StatCommand@685] - Stat command output [junit] 2015-04-30 12:00:08,969 [myid:] - INFO [NIOWorkerThread-1:NIOServerCnxn@1007] - Closed socket connection for client /127.0.0.1:33028 (no session established for client) [junit] 2015-04-30 12:00:08,970 [myid:] - INFO [main:JMXEnv@224] - ensureParent:[InMemoryDataTree, StandaloneServer_port] [junit] 2015-04-30 12:00:08,971 [myid:] - INFO [main:JMXEnv@241] - expect:InMemoryDataTree [junit] 2015-04-30 12:00:08,972 [myid:] - INFO [main:JMXEnv@245] - found:InMemoryDataTree org.apache.ZooKeeperService:name0=StandaloneServer_port11221,name1=InMemoryDataTree [junit] 2015-04-30 12:00:08,972 [myid:] - INFO [main:JMXEnv@241] - expect:StandaloneServer_port [junit] 2015-04-30 12:00:08,972 [myid:] - INFO [main:JMXEnv@245] - found:StandaloneServer_port org.apache.ZooKeeperService:name0=StandaloneServer_port11221 [junit] 2015-04-30 12:00:08,972 [myid:] - INFO [main:JUnit4ZKTestRunner$LoggedInvokeMethod@55] - Memory used 13732 [junit] 2015-04-30 12:00:08,973 [myid:] - INFO [main:JUnit4ZKTestRunner$LoggedInvokeMethod@60] - Number of threads 23 [junit] 2015-04-30 12:00:08,973 [myid:] - INFO [main:JUnit4ZKTestRunner$LoggedInvokeMethod@65] - FINISHED TEST METHOD testQuota [junit] 2015-04-30 12:00:08,973 [myid:] - INFO [main:ClientBase@538] - tearDown starting [junit] 2015-04-30 12:00:09,039 [myid:] - INFO [main:ZooKeeper@] - Session: 0x100012a0e92 closed [junit] 2015-04-30 12:00:09,040 [myid:] - INFO [main:ClientBase@508] - STOPPING server [junit] 2015-04-30 12:00:09,039 [myid:] - INFO [main-EventThread:ClientCnxn$EventThread@531] - EventThread shut down [junit] 2015-04-30 12:00:09,040 [myid:] - INFO [ConnnectionExpirer:NIOServerCnxnFactory$ConnectionExpirerThread@583] - ConnnectionExpirerThread interrupted [junit] 2015-04-30 12:00:09,040 [myid:] - INFO [NIOServerCxnFactory.AcceptThread:0.0.0.0/0.0.0.0:11221:NIOServerCnxnFactory$AcceptThread@219] - accept thread exitted run method [junit] 2015-04-30 12:00:09,040 [myid:] - INFO [NIOServerCxnFactory.SelectorThread-0:NIOServerCnxnFactory$SelectorThread@420] - selector thread exitted run method [junit]
ZooKeeper-trunk - Build # 2677 - Failure
See https://builds.apache.org/job/ZooKeeper-trunk/2677/ ### ## LAST 60 LINES OF THE CONSOLE ### [...truncated 363908 lines...] [junit] 2015-04-30 13:11:06,555 [myid:] - INFO [main:FileTxnSnapLog@298] - Snapshotting: 0xb to /home/jenkins/jenkins-slave/workspace/ZooKeeper-trunk/trunk/build/test/tmp/test8580525472726390305.junit.dir/version-2/snapshot.b [junit] 2015-04-30 13:11:06,558 [myid:] - INFO [main:FourLetterWordMain@63] - connecting to 127.0.0.1 11221 [junit] 2015-04-30 13:11:06,558 [myid:] - INFO [NIOServerCxnFactory.AcceptThread:0.0.0.0/0.0.0.0:11221:NIOServerCnxnFactory$AcceptThread@296] - Accepted socket connection from /127.0.0.1:48477 [junit] 2015-04-30 13:11:06,560 [myid:] - INFO [NIOWorkerThread-1:NIOServerCnxn@836] - Processing stat command from /127.0.0.1:48477 [junit] 2015-04-30 13:11:06,560 [myid:] - INFO [NIOWorkerThread-1:NIOServerCnxn$StatCommand@685] - Stat command output [junit] 2015-04-30 13:11:06,560 [myid:] - INFO [NIOWorkerThread-1:NIOServerCnxn@1007] - Closed socket connection for client /127.0.0.1:48477 (no session established for client) [junit] 2015-04-30 13:11:06,560 [myid:] - INFO [main:JMXEnv@224] - ensureParent:[InMemoryDataTree, StandaloneServer_port] [junit] 2015-04-30 13:11:06,563 [myid:] - INFO [main:JMXEnv@241] - expect:InMemoryDataTree [junit] 2015-04-30 13:11:06,563 [myid:] - INFO [main:JMXEnv@245] - found:InMemoryDataTree org.apache.ZooKeeperService:name0=StandaloneServer_port11221,name1=InMemoryDataTree [junit] 2015-04-30 13:11:06,563 [myid:] - INFO [main:JMXEnv@241] - expect:StandaloneServer_port [junit] 2015-04-30 13:11:06,563 [myid:] - INFO [main:JMXEnv@245] - found:StandaloneServer_port org.apache.ZooKeeperService:name0=StandaloneServer_port11221 [junit] 2015-04-30 13:11:06,564 [myid:] - INFO [main:JUnit4ZKTestRunner$LoggedInvokeMethod@55] - Memory used 85032 [junit] 2015-04-30 13:11:06,564 [myid:] - INFO [main:JUnit4ZKTestRunner$LoggedInvokeMethod@60] - Number of threads 24 [junit] 2015-04-30 13:11:06,564 [myid:] - INFO [main:JUnit4ZKTestRunner$LoggedInvokeMethod@65] - FINISHED TEST METHOD testQuota [junit] 2015-04-30 13:11:06,564 [myid:] - INFO [main:ClientBase@538] - tearDown starting [junit] 2015-04-30 13:11:06,625 [myid:] - INFO [main:ZooKeeper@] - Session: 0x1019a6831de closed [junit] 2015-04-30 13:11:06,625 [myid:] - INFO [main:ClientBase@508] - STOPPING server [junit] 2015-04-30 13:11:06,625 [myid:] - INFO [main-EventThread:ClientCnxn$EventThread@531] - EventThread shut down [junit] 2015-04-30 13:11:06,626 [myid:] - INFO [NIOServerCxnFactory.AcceptThread:0.0.0.0/0.0.0.0:11221:NIOServerCnxnFactory$AcceptThread@219] - accept thread exitted run method [junit] 2015-04-30 13:11:06,626 [myid:] - INFO [NIOServerCxnFactory.SelectorThread-0:NIOServerCnxnFactory$SelectorThread@420] - selector thread exitted run method [junit] 2015-04-30 13:11:06,625 [myid:] - INFO [ConnnectionExpirer:NIOServerCnxnFactory$ConnectionExpirerThread@583] - ConnnectionExpirerThread interrupted [junit] 2015-04-30 13:11:06,626 [myid:] - INFO [NIOServerCxnFactory.SelectorThread-1:NIOServerCnxnFactory$SelectorThread@420] - selector thread exitted run method [junit] 2015-04-30 13:11:06,627 [myid:] - INFO [main:ZooKeeperServer@465] - shutting down [junit] 2015-04-30 13:11:06,627 [myid:] - INFO [main:SessionTrackerImpl@232] - Shutting down [junit] 2015-04-30 13:11:06,627 [myid:] - INFO [main:PrepRequestProcessor@973] - Shutting down [junit] 2015-04-30 13:11:06,627 [myid:] - INFO [main:SyncRequestProcessor@191] - Shutting down [junit] 2015-04-30 13:11:06,627 [myid:] - INFO [ProcessThread(sid:0 cport:11221)::PrepRequestProcessor@155] - PrepRequestProcessor exited loop! [junit] 2015-04-30 13:11:06,628 [myid:] - INFO [SyncThread:0:SyncRequestProcessor@169] - SyncRequestProcessor exited! [junit] 2015-04-30 13:11:06,628 [myid:] - INFO [main:FinalRequestProcessor@489] - shutdown of request processor complete [junit] 2015-04-30 13:11:06,629 [myid:] - INFO [main:MBeanRegistry@119] - Unregister MBean [org.apache.ZooKeeperService:name0=StandaloneServer_port11221,name1=InMemoryDataTree] [junit] 2015-04-30 13:11:06,629 [myid:] - INFO [main:MBeanRegistry@119] - Unregister MBean [org.apache.ZooKeeperService:name0=StandaloneServer_port11221] [junit] 2015-04-30 13:11:06,629 [myid:] - INFO [main:FourLetterWordMain@63] - connecting to 127.0.0.1 11221 [junit] 2015-04-30 13:11:06,630 [myid:] - INFO [main:JMXEnv@142] - ensureOnly:[] [junit] 2015-04-30 13:11:06,634 [myid:] - INFO [main:ClientBase@563] - fdcount after test is: 46 at start it was 34 [junit] 2015-04-30 13:11:06,634 [myid:] - INFO [main:ClientBase@565] - sleeping for 20 secs [junit] 2015-04-30
[jira] [Updated] (ZOOKEEPER-2177) point to md5/sha1/asc files in releases.html
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Nauroth updated ZOOKEEPER-2177: - Attachment: ZOOKEEPER-2177.001.patch [~michim], thank you for filing the jira. I have attached a patch intended for https://svn.apache.org/repos/asf/zookeeper/site . I won't click the Submit Patch button, because I don't think the Jenkins pre-commit automation knows how to work with the site repo. point to md5/sha1/asc files in releases.html Key: ZOOKEEPER-2177 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2177 Project: ZooKeeper Issue Type: Task Reporter: Michi Mutsuzaki Priority: Minor Attachments: ZOOKEEPER-2177.001.patch these files are not mirrored. we should link to these files in http://zookeeper.apache.org/releases.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ZOOKEEPER-2163) Introduce new ZNode type: container
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14521948#comment-14521948
]
Jordan Zimmerman commented on ZOOKEEPER-2163:
-
What about the hacked ephemeralOwner? I'd appreciate committers feedback on
this or suggestions of an alternative.
Introduce new ZNode type: container
---
Key: ZOOKEEPER-2163
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2163
Project: ZooKeeper
Issue Type: New Feature
Components: c client, java client, server
Affects Versions: 3.5.0
Reporter: Jordan Zimmerman
Assignee: Jordan Zimmerman
Attachments: zookeeper-2163.3.patch
BACKGROUND
A recurring problem for ZooKeeper users is garbage collection of parent
nodes. Many recipes (e.g. locks, leaders, etc.) call for the creation of a
parent node under which participants create sequential nodes. When the
participant is done, it deletes its node. In practice, the ZooKeeper tree
begins to fill up with orphaned parent nodes that are no longer needed. The
ZooKeeper APIs don’t provide a way to clean these. Over time, ZooKeeper can
become unstable due to the number of these nodes.
CURRENT SOLUTIONS
===
Apache Curator has a workaround solution for this by providing the Reaper
class which runs in the background looking for orphaned parent nodes and
deleting them. This isn’t ideal and it would be better if ZooKeeper supported
this directly.
PROPOSAL
=
ZOOKEEPER-723 and ZOOKEEPER-834 have been proposed to allow EPHEMERAL nodes
to contain child nodes. This is not optimum as EPHEMERALs are tied to a
session and the general use case of parent nodes is for PERSISTENT nodes.
This proposal adds a new node type, CONTAINER. A CONTAINER node is the same
as a PERSISTENT node with the additional property that when its last child is
deleted, it is deleted (and CONTAINER nodes recursively up the tree are
deleted if empty).
CANONICAL USAGE
{code}
while ( true) { // or some reasonable limit
try {
zk.create(path, ...);
break;
} catch ( KeeperException.NoNodeException e ) {
try {
zk.createContainer(containerPath, ...);
} catch ( KeeperException.NodeExistsException ignore) {
}
}
}
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (ZOOKEEPER-2163) Introduce new ZNode type: container
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14521943#comment-14521943
]
Camille Fournier commented on ZOOKEEPER-2163:
-
Haven't done a super detailed code review but I am +1 with the high-level
implementation, api, etc.
Introduce new ZNode type: container
---
Key: ZOOKEEPER-2163
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2163
Project: ZooKeeper
Issue Type: New Feature
Components: c client, java client, server
Affects Versions: 3.5.0
Reporter: Jordan Zimmerman
Assignee: Jordan Zimmerman
Attachments: zookeeper-2163.3.patch
BACKGROUND
A recurring problem for ZooKeeper users is garbage collection of parent
nodes. Many recipes (e.g. locks, leaders, etc.) call for the creation of a
parent node under which participants create sequential nodes. When the
participant is done, it deletes its node. In practice, the ZooKeeper tree
begins to fill up with orphaned parent nodes that are no longer needed. The
ZooKeeper APIs don’t provide a way to clean these. Over time, ZooKeeper can
become unstable due to the number of these nodes.
CURRENT SOLUTIONS
===
Apache Curator has a workaround solution for this by providing the Reaper
class which runs in the background looking for orphaned parent nodes and
deleting them. This isn’t ideal and it would be better if ZooKeeper supported
this directly.
PROPOSAL
=
ZOOKEEPER-723 and ZOOKEEPER-834 have been proposed to allow EPHEMERAL nodes
to contain child nodes. This is not optimum as EPHEMERALs are tied to a
session and the general use case of parent nodes is for PERSISTENT nodes.
This proposal adds a new node type, CONTAINER. A CONTAINER node is the same
as a PERSISTENT node with the additional property that when its last child is
deleted, it is deleted (and CONTAINER nodes recursively up the tree are
deleted if empty).
CANONICAL USAGE
{code}
while ( true) { // or some reasonable limit
try {
zk.create(path, ...);
break;
} catch ( KeeperException.NoNodeException e ) {
try {
zk.createContainer(containerPath, ...);
} catch ( KeeperException.NodeExistsException ignore) {
}
}
}
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (ZOOKEEPER-2171) avoid reverse lookups in QuorumCnxManager
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14521796#comment-14521796
]
Raul Gutierrez Segales commented on ZOOKEEPER-2171:
---
Hmmm, failed again, thought at a different place:
{noformat}
Error Message
waiting for server 2 being up
Stacktrace
junit.framework.AssertionFailedError: waiting for server 2 being up
at
org.apache.zookeeper.server.quorum.ReconfigRecoveryTest.testCurrentObserverIsParticipantInNewConfig(ReconfigRecoveryTest.java:529)
at
org.apache.zookeeper.JUnit4ZKTestRunner$LoggedInvokeMethod.evaluate(JUnit4ZKTestRunner.java:52)
{noformat}
Could this be a bad CI box? Any ideas? cc: [~michim], [~rakeshr]
avoid reverse lookups in QuorumCnxManager
-
Key: ZOOKEEPER-2171
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2171
Project: ZooKeeper
Issue Type: Bug
Components: quorum
Reporter: Raul Gutierrez Segales
Assignee: Raul Gutierrez Segales
Fix For: 3.5.1, 3.6.0
Attachments: ZOOKEEPER-2171.patch, ZOOKEEPER-2171.patch,
ZOOKEEPER-2171.patch
Apparently, ZOOKEEPER-107 (via a quick git-blame look) introduced a bunch of
getHostName() calls in QCM. Besides the overhead, these can cause problems
when mixed with failing/mis-configured DNS servers.
It would be nice to reduce them, if that doesn't affect operational
correctness.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (ZOOKEEPER-2163) Introduce new ZNode type: container
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14521955#comment-14521955
]
Camille Fournier commented on ZOOKEEPER-2163:
-
I can't think of a better way so I'm OK with it
Introduce new ZNode type: container
---
Key: ZOOKEEPER-2163
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2163
Project: ZooKeeper
Issue Type: New Feature
Components: c client, java client, server
Affects Versions: 3.5.0
Reporter: Jordan Zimmerman
Assignee: Jordan Zimmerman
Attachments: zookeeper-2163.3.patch
BACKGROUND
A recurring problem for ZooKeeper users is garbage collection of parent
nodes. Many recipes (e.g. locks, leaders, etc.) call for the creation of a
parent node under which participants create sequential nodes. When the
participant is done, it deletes its node. In practice, the ZooKeeper tree
begins to fill up with orphaned parent nodes that are no longer needed. The
ZooKeeper APIs don’t provide a way to clean these. Over time, ZooKeeper can
become unstable due to the number of these nodes.
CURRENT SOLUTIONS
===
Apache Curator has a workaround solution for this by providing the Reaper
class which runs in the background looking for orphaned parent nodes and
deleting them. This isn’t ideal and it would be better if ZooKeeper supported
this directly.
PROPOSAL
=
ZOOKEEPER-723 and ZOOKEEPER-834 have been proposed to allow EPHEMERAL nodes
to contain child nodes. This is not optimum as EPHEMERALs are tied to a
session and the general use case of parent nodes is for PERSISTENT nodes.
This proposal adds a new node type, CONTAINER. A CONTAINER node is the same
as a PERSISTENT node with the additional property that when its last child is
deleted, it is deleted (and CONTAINER nodes recursively up the tree are
deleted if empty).
CANONICAL USAGE
{code}
while ( true) { // or some reasonable limit
try {
zk.create(path, ...);
break;
} catch ( KeeperException.NoNodeException e ) {
try {
zk.createContainer(containerPath, ...);
} catch ( KeeperException.NodeExistsException ignore) {
}
}
}
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (ZOOKEEPER-2171) avoid reverse lookups in QuorumCnxManager
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14521986#comment-14521986
]
Raul Gutierrez Segales commented on ZOOKEEPER-2171:
---
Oh well, passes for me locally (again):
{noformat}
...
BUILD SUCCESSFUL
Total time: 47 minutes 44 seconds
{noformat}
So it does sound more like flaky CI :-(
avoid reverse lookups in QuorumCnxManager
-
Key: ZOOKEEPER-2171
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2171
Project: ZooKeeper
Issue Type: Bug
Components: quorum
Reporter: Raul Gutierrez Segales
Assignee: Raul Gutierrez Segales
Fix For: 3.5.1, 3.6.0
Attachments: ZOOKEEPER-2171.patch, ZOOKEEPER-2171.patch,
ZOOKEEPER-2171.patch
Apparently, ZOOKEEPER-107 (via a quick git-blame look) introduced a bunch of
getHostName() calls in QCM. Besides the overhead, these can cause problems
when mixed with failing/mis-configured DNS servers.
It would be nice to reduce them, if that doesn't affect operational
correctness.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (ZOOKEEPER-2177) point to md5/sha1/asc files in releases.html
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Nauroth reassigned ZOOKEEPER-2177: Assignee: Chris Nauroth point to md5/sha1/asc files in releases.html Key: ZOOKEEPER-2177 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2177 Project: ZooKeeper Issue Type: Task Reporter: Michi Mutsuzaki Assignee: Chris Nauroth Priority: Minor Attachments: ZOOKEEPER-2177.001.patch these files are not mirrored. we should link to these files in http://zookeeper.apache.org/releases.html -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ZOOKEEPER-1998) C library calls getaddrinfo unconditionally from zookeeper_interest
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14522078#comment-14522078 ] Joe Smith commented on ZOOKEEPER-1998: -- I've filed MESOS-2681 which tracks Apache Mesos being affected by this as well in the 3.4.x branch. C library calls getaddrinfo unconditionally from zookeeper_interest --- Key: ZOOKEEPER-1998 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1998 Project: ZooKeeper Issue Type: Bug Components: c client Affects Versions: 3.5.0 Reporter: Raul Gutierrez Segales Assignee: Raul Gutierrez Segales Priority: Critical Fix For: 3.5.2, 3.6.0 (commented this on ZOOKEEPER-338) I've just noticed that we call getaddrinfo from zookeeper_interest... on every call. So from zookeeper_interest we always call update_addrs: https://github.com/apache/zookeeper/blob/trunk/src/c/src/zookeeper.c#L2082 which in turns unconditionally calls resolve_hosts: https://github.com/apache/zookeeper/blob/trunk/src/c/src/zookeeper.c#L787 which does the unconditional calls to getaddrinfo: https://github.com/apache/zookeeper/blob/trunk/src/c/src/zookeeper.c#L648 We should fix this since it'll make 3.5.0 slower for people relying on DNS. I think this is happened as part of ZOOKEEPER-107 in which the list of servers can be updated. cc: [~shralex], [~phunt], [~fpj] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ZOOKEEPER-2171) avoid reverse lookups in QuorumCnxManager
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Raul Gutierrez Segales updated ZOOKEEPER-2171: -- Attachment: ZOOKEEPER-2171.patch trying to restart the build avoid reverse lookups in QuorumCnxManager - Key: ZOOKEEPER-2171 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2171 Project: ZooKeeper Issue Type: Bug Components: quorum Reporter: Raul Gutierrez Segales Assignee: Raul Gutierrez Segales Fix For: 3.5.1, 3.6.0 Attachments: ZOOKEEPER-2171.patch, ZOOKEEPER-2171.patch, ZOOKEEPER-2171.patch, ZOOKEEPER-2171.patch Apparently, ZOOKEEPER-107 (via a quick git-blame look) introduced a bunch of getHostName() calls in QCM. Besides the overhead, these can cause problems when mixed with failing/mis-configured DNS servers. It would be nice to reduce them, if that doesn't affect operational correctness. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ZOOKEEPER-2176) unclear error message should be info or warn
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2176?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14522294#comment-14522294
]
Raul Gutierrez Segales commented on ZOOKEEPER-2176:
---
Well, changing a logging statement triggered a build failure. Clearly there's
something up w/ CI.
unclear error message should be info or warn
Key: ZOOKEEPER-2176
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2176
Project: ZooKeeper
Issue Type: Improvement
Components: quorum
Affects Versions: 3.5.0, 3.5.1, 3.5.2
Reporter: Raul Gutierrez Segales
Assignee: Raul Gutierrez Segales
Attachments: ZOOKEEPER-2176.patch
Hi [~shralex],
Looking at the CI output of ZOOKEEPER-2163 I see this:
{noformat}
[exec] [junit] 2015-04-17 17:36:23,750 [myid:] - ERROR
[QuorumPeer[myid=4](plain=/0:0:0:0:0:0:0:0:11235)(secure=disabled):QuorumPeer@1394]
- writeToDisk == true but configFilename == null
{noformat}
Though looking at QuorumPeer#setQuorumVerifier I see:
{noformat}
if (configFilename != null) {
try {
String dynamicConfigFilename = makeDynamicConfigFilename(
qv.getVersion());
QuorumPeerConfig.writeDynamicConfig(
dynamicConfigFilename, qv, false);
QuorumPeerConfig.editStaticConfig(configFilename,
dynamicConfigFilename,
needEraseClientInfoFromStaticConfig());
} catch (IOException e) {
LOG.error(Error closing file: , e.getMessage());
}
} else {
LOG.error(writeToDisk == true but configFilename == null);
}
{noformat}
there's no proper error handling so I guess maybe we should just make it a
warning? Thoughts?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (ZOOKEEPER-2171) avoid reverse lookups in QuorumCnxManager
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14522086#comment-14522086
]
Raul Gutierrez Segales commented on ZOOKEEPER-2171:
---
That was test-core-java, ant test (the full suite) passes too:
{noformat}
...
BUILD SUCCESSFUL
Total time: 52 minutes 9 seconds
{noformat}
I'll resubmit the patch, cancel submit and trigger the build again. Is there
an easier way to re-kick the build?
avoid reverse lookups in QuorumCnxManager
-
Key: ZOOKEEPER-2171
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2171
Project: ZooKeeper
Issue Type: Bug
Components: quorum
Reporter: Raul Gutierrez Segales
Assignee: Raul Gutierrez Segales
Fix For: 3.5.1, 3.6.0
Attachments: ZOOKEEPER-2171.patch, ZOOKEEPER-2171.patch,
ZOOKEEPER-2171.patch
Apparently, ZOOKEEPER-107 (via a quick git-blame look) introduced a bunch of
getHostName() calls in QCM. Besides the overhead, these can cause problems
when mixed with failing/mis-configured DNS servers.
It would be nice to reduce them, if that doesn't affect operational
correctness.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (ZOOKEEPER-2042) zkServer.sh does not work properly on Solaris
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14522805#comment-14522805 ] Chris Nauroth commented on ZOOKEEPER-2042: -- [~jlindwall], thank you for filing the bug report. I'm going to resolve this as a duplicate of ZOOKEEPER-1927. I've added you as a watcher on that issue so that you'll continue to get status updates. I'll post a patch on that issue shortly. zkServer.sh does not work properly on Solaris - Key: ZOOKEEPER-2042 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2042 Project: ZooKeeper Issue Type: Bug Components: scripts Affects Versions: 3.4.6 Environment: Solaris 5.11 Reporter: John Lindwall Priority: Minor There are two issues in the zkServer.sh script that make it not work properly out of the box on Solaris. 1. The bin/zkServer.sh script uses plain echo in all instances but one: when writing the pid to the pid file. In that instance it uses /bin/echo. The /bin/echo command on Solaris does not understand the -n parameter and interprets it as a literal string, so the -n gets written into the pid file along with the pid. This causes the stop command to fail. 2. The /bin/grep command in Solaris does not understand special character classes like [[:space:]]. You must use the alternate posix version of grep as found in /usr/xpg4/bin/grep for this to work. If the script cannot be made completely generic then at least we should document the need to use the posix grep implementation on Solaris. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (ZOOKEEPER-1927) zkServer.sh fails to read dataDir (and others) from zoo.cfg on Solaris 10 (grep issue, manifests as FAILED TO WRITE PID).
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1927?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Nauroth reassigned ZOOKEEPER-1927: Assignee: Chris Nauroth zkServer.sh fails to read dataDir (and others) from zoo.cfg on Solaris 10 (grep issue, manifests as FAILED TO WRITE PID). --- Key: ZOOKEEPER-1927 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1927 Project: ZooKeeper Issue Type: Bug Components: scripts Affects Versions: 3.4.6 Environment: Solaris 5.10 Reporter: Ed Schmed Assignee: Chris Nauroth Attachments: ZOOKEEPER-1927.001.patch Fails to write PID file with a permissions error, because the startup script fails to read the dataDir variable from zoo.cfg, and then tries to use the drive root ( / ) as the data dir. Tracked the problem down to line 84 of zkServer.sh: ZOO_DATADIR=$(grep ^[[:space:]]*dataDir $ZOOCFG | sed -e 's/.*=//') If i run just that line and point it right at the config file, ZOO_DATADIR is empty. If I remove [[:space:]]* from the grep: ZOO_DATADIR=$(grep ^dataDir $ZOOCFG | sed -e 's/.*=//') Then it works fine. (If I also make the same change on line 164 and 169) My regex skills are pretty bad, so I'm afraid to comment on why [[space]]* needs to be in there? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ZOOKEEPER-2078) zkServer.sh uses pattern unsupported by grep on Solaris
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2078?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14522807#comment-14522807
]
Chris Nauroth commented on ZOOKEEPER-2078:
--
[~metatech], thank you for filing the bug report. I'm going to resolve this as
a duplicate of ZOOKEEPER-1927. I've added you as a watcher on that issue so
that you'll continue to get status updates. I'll post a patch on that issue
shortly.
zkServer.sh uses pattern unsupported by grep on Solaris
-
Key: ZOOKEEPER-2078
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2078
Project: ZooKeeper
Issue Type: Bug
Components: scripts
Affects Versions: 3.4.5
Environment: Solaris 11
Reporter: metatech
Priority: Minor
The script zkServer.sh contains a pattern (POSIX character class syntax)
which is not supported by grep on Solaris (both versions 10 and 11).
{code}
ZOO_DATADIR=$(grep ^[[:space:]]*dataDir $ZOOCFG | sed -e 's/.*=//')
{code}
This results into the environment variable being set with an empty value,
which later gives the following error :
{code}
Starting zookeeper ... bin/zkServer.sh: line 114: /zookeeper_server.pid:
Permission denied
{code}
The workaround is to simplify the pattern used by grep :
{code}
ZOO_DATADIR=$(grep ^dataDir $ZOOCFG | sed -e 's/.*=//')
{code}
The same pattern is also used in the status command, which fails to read
the clientPort, which results into the following error :
{code}
Error contacting service. It is probably not running.
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (ZOOKEEPER-1927) zkServer.sh fails to read dataDir (and others) from zoo.cfg on Solaris 10 (grep issue, manifests as FAILED TO WRITE PID).
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1927?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Nauroth updated ZOOKEEPER-1927: - Attachment: ZOOKEEPER-1927.001.patch I'm attaching a patch that does the following: # On Solaris only, call /usr/xpg4/bin/grep. This has the GNU grep semantics that the regex expects. # On Solaris only, use a different incantation of /bin/echo to avoid echoing newline. I tested this patch on both Solaris and CentOS. I built a distro, started and stopped the server, and verified basic operations. zkServer.sh fails to read dataDir (and others) from zoo.cfg on Solaris 10 (grep issue, manifests as FAILED TO WRITE PID). --- Key: ZOOKEEPER-1927 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1927 Project: ZooKeeper Issue Type: Bug Components: scripts Affects Versions: 3.4.6 Environment: Solaris 5.10 Reporter: Ed Schmed Attachments: ZOOKEEPER-1927.001.patch Fails to write PID file with a permissions error, because the startup script fails to read the dataDir variable from zoo.cfg, and then tries to use the drive root ( / ) as the data dir. Tracked the problem down to line 84 of zkServer.sh: ZOO_DATADIR=$(grep ^[[:space:]]*dataDir $ZOOCFG | sed -e 's/.*=//') If i run just that line and point it right at the config file, ZOO_DATADIR is empty. If I remove [[:space:]]* from the grep: ZOO_DATADIR=$(grep ^dataDir $ZOOCFG | sed -e 's/.*=//') Then it works fine. (If I also make the same change on line 164 and 169) My regex skills are pretty bad, so I'm afraid to comment on why [[space]]* needs to be in there? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (ZOOKEEPER-2078) zkServer.sh uses pattern unsupported by grep on Solaris
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2078?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris Nauroth resolved ZOOKEEPER-2078.
--
Resolution: Duplicate
Assignee: Chris Nauroth
zkServer.sh uses pattern unsupported by grep on Solaris
-
Key: ZOOKEEPER-2078
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2078
Project: ZooKeeper
Issue Type: Bug
Components: scripts
Affects Versions: 3.4.5
Environment: Solaris 11
Reporter: metatech
Assignee: Chris Nauroth
Priority: Minor
The script zkServer.sh contains a pattern (POSIX character class syntax)
which is not supported by grep on Solaris (both versions 10 and 11).
{code}
ZOO_DATADIR=$(grep ^[[:space:]]*dataDir $ZOOCFG | sed -e 's/.*=//')
{code}
This results into the environment variable being set with an empty value,
which later gives the following error :
{code}
Starting zookeeper ... bin/zkServer.sh: line 114: /zookeeper_server.pid:
Permission denied
{code}
The workaround is to simplify the pattern used by grep :
{code}
ZOO_DATADIR=$(grep ^dataDir $ZOOCFG | sed -e 's/.*=//')
{code}
The same pattern is also used in the status command, which fails to read
the clientPort, which results into the following error :
{code}
Error contacting service. It is probably not running.
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (ZOOKEEPER-2042) zkServer.sh does not work properly on Solaris
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2042?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Chris Nauroth resolved ZOOKEEPER-2042. -- Resolution: Duplicate Assignee: Chris Nauroth zkServer.sh does not work properly on Solaris - Key: ZOOKEEPER-2042 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2042 Project: ZooKeeper Issue Type: Bug Components: scripts Affects Versions: 3.4.6 Environment: Solaris 5.11 Reporter: John Lindwall Assignee: Chris Nauroth Priority: Minor There are two issues in the zkServer.sh script that make it not work properly out of the box on Solaris. 1. The bin/zkServer.sh script uses plain echo in all instances but one: when writing the pid to the pid file. In that instance it uses /bin/echo. The /bin/echo command on Solaris does not understand the -n parameter and interprets it as a literal string, so the -n gets written into the pid file along with the pid. This causes the stop command to fail. 2. The /bin/grep command in Solaris does not understand special character classes like [[:space:]]. You must use the alternate posix version of grep as found in /usr/xpg4/bin/grep for this to work. If the script cannot be made completely generic then at least we should document the need to use the posix grep implementation on Solaris. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ZOOKEEPER-2174) JUnit4ZKTestRunner logs test failure for all exceptions even if the test method is annotated with an expected exception.
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris Nauroth updated ZOOKEEPER-2174:
-
Attachment: ZOOKEEPER-2174-branch-3.4.004.patch
Hello [~rgs]. Here is a patch for branch-3.4. Thank you!
JUnit4ZKTestRunner logs test failure for all exceptions even if the test
method is annotated with an expected exception.
Key: ZOOKEEPER-2174
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2174
Project: ZooKeeper
Issue Type: Bug
Components: tests
Reporter: Chris Nauroth
Assignee: Chris Nauroth
Priority: Minor
Fix For: 3.4.7, 3.5.2, 3.6.0
Attachments: ZOOKEEPER-2174-branch-3.4.004.patch,
ZOOKEEPER-2174.001.patch, ZOOKEEPER-2174.002.patch, ZOOKEEPER-2174.003.patch,
ZOOKEEPER-2174.004.patch
{{JUnit4ZKTestRunner}} wraps JUnit test method execution, and if any
exception is thrown, it logs a message stating that the test failed.
However, some ZooKeeper tests are annotated with {{@Test(expected=...)}} to
indicate that an exception is the expected result, and thus the test passes.
The runner should be aware of expected exceptions and only log if an
unexpected exception occurs.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (ZOOKEEPER-1866) ClientBase#createClient is failing frequently
[
https://issues.apache.org/jira/browse/ZOOKEEPER-1866?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14522315#comment-14522315
]
Raul Gutierrez Segales commented on ZOOKEEPER-1866:
---
Hi [~abranzyck], [~fpj], [~rakeshr]:
ZOOKEEPER-1872 has been merged for the 3.4 branch - is this still happening?
I'd like to get things going for the 3.4.7 release. Thanks!
ClientBase#createClient is failing frequently
-
Key: ZOOKEEPER-1866
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1866
Project: ZooKeeper
Issue Type: Sub-task
Components: tests
Affects Versions: 3.4.5
Reporter: Rakesh R
Assignee: Germán Blanco
Fix For: 3.4.7
Attachments: ZOOKEEPER-1866.patch
Following failure pattern has been observed many times in windows build.
After creating the zookeeper client, the respective connection bean is not
available in the jmx beans and is failing the tests.
{code}
[junit] 2014-01-22 08:58:22,625 [myid:] - INFO [main:ZKTestCase$1@65] -
FAILED testInvalidVersion
[junit] junit.framework.AssertionFailedError: expected
[0x143b92b0333] expected:1 but was:0
[junit] at junit.framework.Assert.fail(Assert.java:47)
[junit] at junit.framework.Assert.failNotEquals(Assert.java:283)
[junit] at junit.framework.Assert.assertEquals(Assert.java:64)
[junit] at junit.framework.Assert.assertEquals(Assert.java:195)
[junit] at org.apache.zookeeper.test.JMXEnv.ensureAll(JMXEnv.java:124)
[junit] at
org.apache.zookeeper.test.ClientBase.createClient(ClientBase.java:191)
[junit] at
org.apache.zookeeper.test.ClientBase.createClient(ClientBase.java:171)
[junit] at
org.apache.zookeeper.test.ClientBase.createClient(ClientBase.java:156)
[junit] at
org.apache.zookeeper.test.ClientBase.createClient(ClientBase.java:149)
[junit] at
org.apache.zookeeper.test.MultiTransactionTest.setUp(MultiTransactionTest.java:60)
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (ZOOKEEPER-1884) zkCli silently ignores commands with missing parameters
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1884?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Raul Gutierrez Segales updated ZOOKEEPER-1884: -- Summary: zkCli silently ignores commands with missing parameters (was: zkCli silently ignores a create when only the path is given) zkCli silently ignores commands with missing parameters --- Key: ZOOKEEPER-1884 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1884 Project: ZooKeeper Issue Type: Bug Affects Versions: 3.4.6 Reporter: Flavio Junqueira Assignee: Flavio Junqueira Priority: Minor Fix For: 3.4.7 Apparently, we have fixed this in trunk, but not in the 3.4 branch. When we pass only the path to create, the command is not executed because it expects an additional parameter and there is no error message because the create command exists. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (ZOOKEEPER-1884) zkCli silently ignores commands with missing parameters
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1884?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Raul Gutierrez Segales reassigned ZOOKEEPER-1884: - Assignee: Raul Gutierrez Segales (was: Flavio Junqueira) zkCli silently ignores commands with missing parameters --- Key: ZOOKEEPER-1884 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1884 Project: ZooKeeper Issue Type: Bug Affects Versions: 3.4.6 Reporter: Flavio Junqueira Assignee: Raul Gutierrez Segales Priority: Minor Fix For: 3.4.7 Apparently, we have fixed this in trunk, but not in the 3.4 branch. When we pass only the path to create, the command is not executed because it expects an additional parameter and there is no error message because the create command exists. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: zookeeper-3.4.7 timeframe
Hi all, I went over all the tickets and I think we should be able to close them over the next week: http://goo.gl/6Jjtj1 After that, I'll cut an RC if that sounds reasonable. Thanks! -rgs On 21 April 2015 at 21:22, Patrick Hunt ph...@apache.org wrote: That's always going to be the case. There will be some changes you know about, and some that you don't. The job of the release manager is to cut the release via the release process (well documented steps). You don't necessarily know about every change - otw we'd never get out releases. ;-) Patrick On Sun, Apr 19, 2015 at 10:10 AM, Hongchao Deng fengjingc...@hotmail.com wrote: By strange I mean not familiar with :) - Hongchao Deng Subject: Re: zookeeper-3.4.7 timeframe From: fpjunque...@yahoo.com.INVALID Date: Sun, 19 Apr 2015 17:26:34 +0100 To: dev@zookeeper.apache.org What's strange about the issues resolved? -Flavio On 18 Apr 2015, at 20:19, Hongchao Deng fengjingc...@hotmail.com wrote: TBH the commits from 3.4.6 to latest look a little strange to me. I don't think I could take that responsibility. I would like to do the RM job for 3.5.2 :) - Hongchao Deng From: ph...@apache.org Date: Fri, 17 Apr 2015 08:30:13 -0700 Subject: Re: zookeeper-3.4.7 timeframe To: dev@zookeeper.apache.org; fpjunque...@yahoo.com One of our new committers perhaps? Hongchao or Raul interested? Patrick On Fri, Apr 17, 2015 at 1:20 AM, Flavio Junqueira fpjunque...@yahoo.com.invalid wrote: I have volunteered to RM 3.4.7, but I'm more than happy to pass if anyone else wants to do a release. -Flavio On Friday, April 17, 2015 8:22 AM, Michi Mutsuzaki mutsuz...@gmail.com wrote: Hi Konstantin, Yes, I'd like us to start preparing for 3.4.7 soon. We have 36 out of 44 issues resolved. Any volunteer to manage the 3.4.7 release? I'd like to get more committers to get familiarized with the release process. On Thu, Apr 16, 2015 at 4:25 PM, Konstantin Boudnik c...@apache.org wrote: Hello ZK team! We are looking into upgrading ZK to 3.4.6 in the coming Bigtop 1.0 release. However, as expressed in BIGTOP-1468, we are concerned a bit about deviating from 'official release only' policy we had so far. But as explained above, there are a few issues that are we need to address if we want to switch: ZOOKEEPER-1911 ZOOKEEPER-2064 ZOOKEEPER-1506 (potentially) I was wondering if you guys are planning on releasing 3.4.7 soon, that will hopefully address at least the top two issues? I am not subscribed to dev@zookeeper.a.o so I'd appreciate if you can include dev@bigtop.a.o into your reply as well. Thanks in advance! Cos
[jira] [Commented] (ZOOKEEPER-1274) Support child watches to be displayed with 4 letter zookeeper commands (i.e. wchs, wchp and wchc)
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14522574#comment-14522574 ] Raul Gutierrez Segales commented on ZOOKEEPER-1274: --- Hi [~cnauroth] - it would be great if you could rebase the patch on trunk. Also, as Patrick mentioned, it would be nice to also extend that command expose through the Jetty server to have it have the same functionality. Thanks! Support child watches to be displayed with 4 letter zookeeper commands (i.e. wchs, wchp and wchc) - Key: ZOOKEEPER-1274 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1274 Project: ZooKeeper Issue Type: Bug Components: server Environment: Zookeeper Server Reporter: amith Assignee: Raul Gutierrez Segales Fix For: 3.5.2, 3.6.0 Attachments: 0001-ZOOKEEPER-1274.-Display-child-watches-info-in-watch-.patch, ZOOKEEPER-1274.patch currently only data watchers (created by exists() and getdata() )are getting displayed with wchs,wchp,wchc 4 letter command command It would be useful to get the infomation related to childwatchers ( getChildren() ) also with 4 letter words. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Failed: ZOOKEEPER-2033 PreCommit Build #2661
Jira: https://issues.apache.org/jira/browse/ZOOKEEPER-2033 Build: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/2661/ ### ## LAST 60 LINES OF THE CONSOLE ### [...truncated 91 lines...] [exec] 2 out of 2 hunks FAILED -- saving rejects to file src/java/main/org/apache/zookeeper/server/quorum/LearnerHandler.java.rej [exec] patching file src/java/test/org/apache/zookeeper/server/quorum/QuorumPeerMainTest.java [exec] Hunk #1 FAILED at 795. [exec] 1 out of 1 hunk FAILED -- saving rejects to file src/java/test/org/apache/zookeeper/server/quorum/QuorumPeerMainTest.java.rej [exec] PATCH APPLICATION FAILED [exec] [exec] [exec] [exec] [exec] -1 overall. Here are the results of testing the latest attachment [exec] http://issues.apache.org/jira/secure/attachment/12667913/ZOOKEEPER-2033-3.4.patch [exec] against trunk revision 1676359. [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 patch. The patch command could not apply the patch. [exec] [exec] Console output: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/2661//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] 314b9597c416cf7679c83788d2ad22444a6b35b3 logged out [exec] [exec] [exec] == [exec] == [exec] Finished build. [exec] == [exec] == [exec] [exec] BUILD FAILED /home/jenkins/jenkins-slave/workspace/PreCommit-ZOOKEEPER-Build/trunk/build.xml:1721: exec returned: 1 Total time: 40 seconds Build step 'Execute shell' marked build as failure Archiving artifacts Sending artifact delta relative to PreCommit-ZOOKEEPER-Build #2660 Archived 1 artifacts Archive block size is 32768 Received 0 blocks and 60637 bytes Compression is 0.0% Took 8.1 sec Recording test results Description set: ZOOKEEPER-2033 Email was triggered for: Failure Sending email for trigger: Failure ### ## FAILED TESTS (if any) ## No tests ran.
[jira] [Commented] (ZOOKEEPER-1884) zkCli silently ignores commands with missing parameters
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14522726#comment-14522726 ] Hadoop QA commented on ZOOKEEPER-1884: -- -1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12729677/ZOOKEEPER-1884.patch against trunk revision 1676359. +1 @author. The patch does not contain any @author tags. -1 tests included. The patch doesn't appear to include any new or modified tests. Please justify why no new tests are needed for this patch. Also please list what manual steps were performed to verify this patch. -1 patch. The patch command could not apply the patch. Console output: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/2662//console This message is automatically generated. zkCli silently ignores commands with missing parameters --- Key: ZOOKEEPER-1884 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1884 Project: ZooKeeper Issue Type: Bug Affects Versions: 3.4.6 Reporter: Flavio Junqueira Assignee: Raul Gutierrez Segales Priority: Minor Fix For: 3.4.7 Attachments: ZOOKEEPER-1884.patch Apparently, we have fixed this in trunk, but not in the 3.4 branch. When we pass only the path to create, the command is not executed because it expects an additional parameter and there is no error message because the create command exists. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Failed: ZOOKEEPER-1884 PreCommit Build #2662
Jira: https://issues.apache.org/jira/browse/ZOOKEEPER-1884 Build: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/2662/ ### ## LAST 60 LINES OF THE CONSOLE ### [...truncated 91 lines...] [exec] Hunk #1 FAILED at 813. [exec] 1 out of 1 hunk FAILED -- saving rejects to file src/java/main/org/apache/zookeeper/ZooKeeperMain.java.rej [exec] PATCH APPLICATION FAILED [exec] [exec] [exec] [exec] [exec] -1 overall. Here are the results of testing the latest attachment [exec] http://issues.apache.org/jira/secure/attachment/12729677/ZOOKEEPER-1884.patch [exec] against trunk revision 1676359. [exec] [exec] +1 @author. The patch does not contain any @author tags. [exec] [exec] -1 tests included. The patch doesn't appear to include any new or modified tests. [exec] Please justify why no new tests are needed for this patch. [exec] Also please list what manual steps were performed to verify this patch. [exec] [exec] -1 patch. The patch command could not apply the patch. [exec] [exec] Console output: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/2662//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] 3240147b78171237c9cf1d193879281b7be799df logged out [exec] [exec] [exec] == [exec] == [exec] Finished build. [exec] == [exec] == [exec] [exec] BUILD FAILED /home/jenkins/jenkins-slave/workspace/PreCommit-ZOOKEEPER-Build/trunk/build.xml:1721: exec returned: 1 Total time: 42 seconds Build step 'Execute shell' marked build as failure Archiving artifacts Sending artifact delta relative to PreCommit-ZOOKEEPER-Build #2660 Archived 1 artifacts Archive block size is 32768 Received 0 blocks and 60637 bytes Compression is 0.0% Took 8.6 sec Recording test results Description set: ZOOKEEPER-1884 Email was triggered for: Failure Sending email for trigger: Failure ### ## FAILED TESTS (if any) ## No tests ran.
[jira] [Commented] (ZOOKEEPER-2175) Checksum validation for malformed packets needs to handle.
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14522561#comment-14522561
]
Brahma Reddy Battula commented on ZOOKEEPER-2175:
-
Thanks [~rakeshr] and [~cnauroth] for looking into this issue..
[~rakeshr] I agree with [~cnauroth] ( just pasting chris comments as I also
want to stress these points)
The data is not private, so there might not be a strong motivation for an HDFS
deployment to enable ZooKeeper wire encryption..
what would you think of a feature request to support a checksum validation when
wire encryption is not used?
[~cnauroth] I responded for your comments in HDFS-8161
Checksum validation for malformed packets needs to handle.
--
Key: ZOOKEEPER-2175
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2175
Project: ZooKeeper
Issue Type: Bug
Reporter: Brahma Reddy Battula
*Session Id from ZK :*
2015-04-15 21:24:54,257 | INFO | CommitProcessor:22 | Established session
0x164cb2b3e4b36ae4 with negotiated timeout 45000 for client
/160.149.0.117:44586 |
org.apache.zookeeper.server.ZooKeeperServer.finishSessionInit(ZooKeeperServer.java:623)
2015-04-15 21:24:54,261 | INFO |
NIOServerCxn.Factory:160-149-0-114/160.149.0.114:24002 | Successfully
authenticated client: authenticationID=hdfs/had...@hadoop.com;
authorizationID=hdfs/had...@hadoop.com. |
org.apache.zookeeper.server.auth.SaslServerCallbackHandler.handleAuthorizeCallback(SaslServerCallbackHandler.java:118)
2015-04-15 21:24:54,261 | INFO |
NIOServerCxn.Factory:160-149-0-114/160.149.0.114:24002 | Setting
authorizedID: hdfs/had...@hadoop.com |
org.apache.zookeeper.server.auth.SaslServerCallbackHandler.handleAuthorizeCallback(SaslServerCallbackHandler.java:134)
2015-04-15 21:24:54,261 | INFO |
NIOServerCxn.Factory:160-149-0-114/160.149.0.114:24002 | adding SASL
authorization for authorizationID: hdfs/had...@hadoop.com |
org.apache.zookeeper.server.ZooKeeperServer.processSasl(ZooKeeperServer.java:1009)
2015-04-15 21:24:54,262 | INFO | ProcessThread(sid:22 cport:-1): | Got
user-level KeeperException when processing
*{color:red}sessionid:0x164cb2b3e4b36ae4{color}* type:create cxid:0x3
zxid:0x20009fafc txntype:-1 reqpath:n/a Error
Path:/hadoop-ha/hacluster/ActiveStandbyElectorLock Error:KeeperErrorCode =
NodeExists for /hadoop-ha/hacluster/ActiveStandbyElectorLock |
org.apache.zookeeper.server.PrepRequestProcessor.pRequest(PrepRequestProcessor.java:648)
*ZKFC Received :* ZK client
2015-04-15 21:24:54,237 | INFO | main-SendThread(160-149-0-114:24002) |
Socket connection established to 160-149-0-114/160.149.0.114:24002,
initiating session |
org.apache.zookeeper.ClientCnxn$SendThread.primeConnection(ClientCnxn.java:854)
2015-04-15 21:24:54,257 | INFO | main-SendThread(160-149-0-114:24002) |
Session establishment complete on server 160-149-0-114/160.149.0.114:24002,
*{color:blue}sessionid = 0x144cb2b3e4b36ae4 {color}* , negotiated timeout =
45000 |
org.apache.zookeeper.ClientCnxn$SendThread.onConnected(ClientCnxn.java:1259)
2015-04-15 21:24:54,260 | INFO | main-EventThread | EventThread shut down |
org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:512)
2015-04-15 21:24:54,262 | INFO | main-EventThread | Session connected. |
org.apache.hadoop.ha.ActiveStandbyElector.processWatchEvent(ActiveStandbyElector.java:547)
2015-04-15 21:24:54,264 | INFO | main-EventThread | Successfully
authenticated to ZooKeeper using SASL. |
org.apache.hadoop.ha.ActiveStandbyElector.processWatchEvent(ActiveStandbyElector.java:573)
one bit corrupted..please check the following for same..
144cb2b3e4b36ae4=101000100110010110010101100100100101100110110101011100100
164cb2b3e4b36ae4=101100100110010110010101100100100101100110110101011100100
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (ZOOKEEPER-2174) JUnit4ZKTestRunner logs test failure for all exceptions even if the test method is annotated with an expected exception.
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2174?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14522562#comment-14522562
]
Raul Gutierrez Segales commented on ZOOKEEPER-2174:
---
Thanks for the patch [~cnauroth]! Could you generate one for the 3.4 branch as
well please?
[~rakeshr]: shall I commit the available one to trunk 3.5?
JUnit4ZKTestRunner logs test failure for all exceptions even if the test
method is annotated with an expected exception.
Key: ZOOKEEPER-2174
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2174
Project: ZooKeeper
Issue Type: Bug
Components: tests
Reporter: Chris Nauroth
Assignee: Chris Nauroth
Priority: Minor
Fix For: 3.4.7, 3.5.2, 3.6.0
Attachments: ZOOKEEPER-2174.001.patch, ZOOKEEPER-2174.002.patch,
ZOOKEEPER-2174.003.patch, ZOOKEEPER-2174.004.patch
{{JUnit4ZKTestRunner}} wraps JUnit test method execution, and if any
exception is thrown, it logs a message stating that the test failed.
However, some ZooKeeper tests are annotated with {{@Test(expected=...)}} to
indicate that an exception is the expected result, and thus the test passes.
The runner should be aware of expected exceptions and only log if an
unexpected exception occurs.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (ZOOKEEPER-2033) zookeeper follower fails to start after a restart immediately following a new epoch
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2033?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14522647#comment-14522647 ] Hadoop QA commented on ZOOKEEPER-2033: -- -1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12667913/ZOOKEEPER-2033-3.4.patch against trunk revision 1676359. +1 @author. The patch does not contain any @author tags. +1 tests included. The patch appears to include 3 new or modified tests. -1 patch. The patch command could not apply the patch. Console output: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/2661//console This message is automatically generated. zookeeper follower fails to start after a restart immediately following a new epoch --- Key: ZOOKEEPER-2033 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2033 Project: ZooKeeper Issue Type: Bug Components: quorum Affects Versions: 3.4.6 Reporter: Asad Saeed Assignee: Asad Saeed Fix For: 3.4.7 Attachments: ZOOKEEPER-2033-3.4.patch, ZOOKEEPER-2033.patch The following issue was seen when adding a new node to a zookeeper cluster. Reproduction steps 1. Create a 2 node ensemble. Write some keys. 2. Add another node to the ensemble, by modifying the config. Restarting entire cluster. 3. Restart the new node before writing any new keys. What occurs is that the new node gets a SNAP from the newly elected leader, since it is too far behind. The zxid for this snapshot is from the new epoch but that is not in the committed log cache. On restart of this new node. The follower sends the new epoch zxid. The leader looks at it's maxCommitted logs, and sees that it is not the newest epoch, and therefore sends a TRUNC. The follower sees the TRUNC but it only has a snapshot, so it cannot truncate! -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (ZOOKEEPER-1884) zkCli silently ignores commands with missing parameters
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1884?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Raul Gutierrez Segales updated ZOOKEEPER-1884: -- Attachment: ZOOKEEPER-1884.patch More generally, zkCli was not issuing warnings when the command existed *but* the number of parameters was wrong. This patch changes things so that usage() is called if there's no match (regardless of the command being known or not). cc: [~michim], [~hdeng], [~fpj] zkCli silently ignores commands with missing parameters --- Key: ZOOKEEPER-1884 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1884 Project: ZooKeeper Issue Type: Bug Affects Versions: 3.4.6 Reporter: Flavio Junqueira Assignee: Raul Gutierrez Segales Priority: Minor Fix For: 3.4.7 Attachments: ZOOKEEPER-1884.patch Apparently, we have fixed this in trunk, but not in the 3.4 branch. When we pass only the path to create, the command is not executed because it expects an additional parameter and there is no error message because the create command exists. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ZOOKEEPER-2171) avoid reverse lookups in QuorumCnxManager
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14522451#comment-14522451 ] Hadoop QA commented on ZOOKEEPER-2171: -- +1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12729616/ZOOKEEPER-2171.patch against trunk revision 1676359. +1 @author. The patch does not contain any @author tags. +1 tests included. The patch appears to include 11 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 2.0.3) 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/2660//testReport/ Findbugs warnings: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/2660//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html Console output: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/2660//console This message is automatically generated. avoid reverse lookups in QuorumCnxManager - Key: ZOOKEEPER-2171 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2171 Project: ZooKeeper Issue Type: Bug Components: quorum Reporter: Raul Gutierrez Segales Assignee: Raul Gutierrez Segales Fix For: 3.5.1, 3.6.0 Attachments: ZOOKEEPER-2171.patch, ZOOKEEPER-2171.patch, ZOOKEEPER-2171.patch, ZOOKEEPER-2171.patch Apparently, ZOOKEEPER-107 (via a quick git-blame look) introduced a bunch of getHostName() calls in QCM. Besides the overhead, these can cause problems when mixed with failing/mis-configured DNS servers. It would be nice to reduce them, if that doesn't affect operational correctness. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Success: ZOOKEEPER-2171 PreCommit Build #2660
Jira: https://issues.apache.org/jira/browse/ZOOKEEPER-2171 Build: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/2660/ ### ## LAST 60 LINES OF THE CONSOLE ### [...truncated 366316 lines...] [exec] +1 overall. Here are the results of testing the latest attachment [exec] http://issues.apache.org/jira/secure/attachment/12729616/ZOOKEEPER-2171.patch [exec] against trunk revision 1676359. [exec] [exec] +1 @author. The patch does not contain any @author tags. [exec] [exec] +1 tests included. The patch appears to include 11 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 2.0.3) 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/2660//testReport/ [exec] Findbugs warnings: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/2660//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html [exec] Console output: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/2660//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] 08d8e82d95569e0cc797d38e170582e431d75fac logged out [exec] [exec] [exec] == [exec] == [exec] Finished build. [exec] == [exec] == [exec] [exec] BUILD SUCCESSFUL Total time: 51 minutes 51 seconds Archiving artifacts Sending artifact delta relative to PreCommit-ZOOKEEPER-Build #2654 Archived 24 artifacts Archive block size is 32768 Received 2 blocks and 33604175 bytes Compression is 0.2% Took 11 sec Recording test results Description set: ZOOKEEPER-2171 Email was triggered for: Success Sending email for trigger: Success ### ## FAILED TESTS (if any) ## All tests passed
[jira] [Commented] (ZOOKEEPER-1402) Upload Zookeeper package to Maven Central
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14522391#comment-14522391 ] Raul Gutierrez Segales commented on ZOOKEEPER-1402: --- Potentially slightly related: https://issues.apache.org/jira/browse/ZOOKEEPER-2177. That being said, this is not a blocker for 3.4.7 per se but something we need to do afterwards. Upload Zookeeper package to Maven Central - Key: ZOOKEEPER-1402 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1402 Project: ZooKeeper Issue Type: Improvement Affects Versions: 3.3.4 Reporter: Igor Lazebny Assignee: Flavio Junqueira Priority: Minor Fix For: 3.4.7 It would be great to make Zookeeper package available in Maven Central as other Apache projects do (Camel, CXF, ActiveMQ, Karaf, etc). That would simplify usage of this package in maven builds. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ZOOKEEPER-1868) Server not coming back up in QuorumZxidSyncTest
[
https://issues.apache.org/jira/browse/ZOOKEEPER-1868?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14522330#comment-14522330
]
Raul Gutierrez Segales commented on ZOOKEEPER-1868:
---
Hi [~fpj],
is this still happening for you? A few things have been merged to the 3.4
branch, so maybe it went away.
Server not coming back up in QuorumZxidSyncTest
---
Key: ZOOKEEPER-1868
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1868
Project: ZooKeeper
Issue Type: Sub-task
Reporter: Flavio Junqueira
Fix For: 3.4.7
Attachments: QuorumZxidSyncTest-output.txt
We got this stack trace:
{noformat}
[junit] 2014-01-27 09:14:08,481 [myid:] - INFO [main:ZKTestCase$1@65] -
FAILED testLateLogs
[junit] java.lang.AssertionError: waiting for server up
[junit] at org.junit.Assert.fail(Assert.java:91)
[junit] at org.junit.Assert.assertTrue(Assert.java:43)
[junit] at
org.apache.zookeeper.test.QuorumBase.startServers(QuorumBase.java:188)
[junit] at
org.apache.zookeeper.test.QuorumBase.startServers(QuorumBase.java:113)
[junit] at
org.apache.zookeeper.test.QuorumZxidSyncTest.testLateLogs(QuorumZxidSyncTest.java:116)
{noformat}
which occurs here, when we stop the servers and restart them.
{noformat}
qb.shutdownServers();
qb.startServers();
{noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (ZOOKEEPER-2033) zookeeper follower fails to start after a restart immediately following a new epoch
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2033?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14522342#comment-14522342 ] Raul Gutierrez Segales commented on ZOOKEEPER-2033: --- Patch generally lgtm. Could you take a look [~fpj]? I'll try to restart CI as well. Thanks! zookeeper follower fails to start after a restart immediately following a new epoch --- Key: ZOOKEEPER-2033 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2033 Project: ZooKeeper Issue Type: Bug Components: quorum Affects Versions: 3.4.6 Reporter: Asad Saeed Assignee: Asad Saeed Fix For: 3.4.7 Attachments: ZOOKEEPER-2033-3.4.patch, ZOOKEEPER-2033.patch The following issue was seen when adding a new node to a zookeeper cluster. Reproduction steps 1. Create a 2 node ensemble. Write some keys. 2. Add another node to the ensemble, by modifying the config. Restarting entire cluster. 3. Restart the new node before writing any new keys. What occurs is that the new node gets a SNAP from the newly elected leader, since it is too far behind. The zxid for this snapshot is from the new epoch but that is not in the committed log cache. On restart of this new node. The follower sends the new epoch zxid. The leader looks at it's maxCommitted logs, and sees that it is not the newest epoch, and therefore sends a TRUNC. The follower sees the TRUNC but it only has a snapshot, so it cannot truncate! -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ZOOKEEPER-1853) zkCli.sh can't issue a CREATE command containing spaces in the data
[
https://issues.apache.org/jira/browse/ZOOKEEPER-1853?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14522531#comment-14522531
]
Raul Gutierrez Segales commented on ZOOKEEPER-1853:
---
Thanks for the patch [~ryanlamore]! Though, could you generate one against the
3.4 branch, the one you uploaded seems to be against trunk.
Other than that, lgtm +1
zkCli.sh can't issue a CREATE command containing spaces in the data
---
Key: ZOOKEEPER-1853
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1853
Project: ZooKeeper
Issue Type: Bug
Components: java client
Affects Versions: 3.4.6, 3.5.0
Reporter: sekine coulibaly
Assignee: Ryan Lamore
Priority: Minor
Labels: patch
Fix For: 3.4.7, 3.5.2
Attachments: ZOOKEEPER-1853.patch, ZOOKEEPER-1853.patch,
ZOOKEEPER-1853.patch, ZkSpaceMan.java
Execute the following command in zkCli.sh :
create /contacts/1 {country:CA,name:De La Salle}
The results is that only {id:1,fullname:De is stored.
The expected result is to have the full JSON payload stored.
The CREATE command seems to be croped after the first space of the data
payload. When issuing a create command, all arguments not being -s nor -e
shall be treated as the actual data.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (ZOOKEEPER-2175) Checksum validation for malformed packets needs to handle.
[
https://issues.apache.org/jira/browse/ZOOKEEPER-2175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14521703#comment-14521703
]
Chris Nauroth commented on ZOOKEEPER-2175:
--
Hi [~brahmareddy]. I agree with Rakesh that this is excellent debugging work!
Thank you for posting the details.
[~rakeshr], what would you think of a feature request to support a checksum
validation when wire encryption is not used? I'd be happy to help. Our use
case is HDFS NameNode HA, which relies on 2 NameNode processes coordinating on
a distributed lock in ZooKeeper. The data is not private, so there might not
be a strong motivation for an HDFS deployment to enable ZooKeeper wire
encryption.
[~brahmareddy], the HDFS logic in this area is driven by ZooKeeper status code
checks like the following in {{ActiveStandbyElector}}:
{code}
private static boolean isSuccess(Code code) {
return (code == Code.OK);
}
{code}
I'm wondering if there is something that we can do in the HDFS code to check
for a specific ZooKeeper status code, and then reconnect our session and retry
taking the lock instead of transitioning to standby. Do you know if there was
a particular ZooKeeper status code that you saw when this happened? Do you
have capability to repro consistently?
I'll comment on HDFS-8161 too.
Checksum validation for malformed packets needs to handle.
--
Key: ZOOKEEPER-2175
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2175
Project: ZooKeeper
Issue Type: Bug
Reporter: Brahma Reddy Battula
*Session Id from ZK :*
2015-04-15 21:24:54,257 | INFO | CommitProcessor:22 | Established session
0x164cb2b3e4b36ae4 with negotiated timeout 45000 for client
/160.149.0.117:44586 |
org.apache.zookeeper.server.ZooKeeperServer.finishSessionInit(ZooKeeperServer.java:623)
2015-04-15 21:24:54,261 | INFO |
NIOServerCxn.Factory:160-149-0-114/160.149.0.114:24002 | Successfully
authenticated client: authenticationID=hdfs/had...@hadoop.com;
authorizationID=hdfs/had...@hadoop.com. |
org.apache.zookeeper.server.auth.SaslServerCallbackHandler.handleAuthorizeCallback(SaslServerCallbackHandler.java:118)
2015-04-15 21:24:54,261 | INFO |
NIOServerCxn.Factory:160-149-0-114/160.149.0.114:24002 | Setting
authorizedID: hdfs/had...@hadoop.com |
org.apache.zookeeper.server.auth.SaslServerCallbackHandler.handleAuthorizeCallback(SaslServerCallbackHandler.java:134)
2015-04-15 21:24:54,261 | INFO |
NIOServerCxn.Factory:160-149-0-114/160.149.0.114:24002 | adding SASL
authorization for authorizationID: hdfs/had...@hadoop.com |
org.apache.zookeeper.server.ZooKeeperServer.processSasl(ZooKeeperServer.java:1009)
2015-04-15 21:24:54,262 | INFO | ProcessThread(sid:22 cport:-1): | Got
user-level KeeperException when processing
*{color:red}sessionid:0x164cb2b3e4b36ae4{color}* type:create cxid:0x3
zxid:0x20009fafc txntype:-1 reqpath:n/a Error
Path:/hadoop-ha/hacluster/ActiveStandbyElectorLock Error:KeeperErrorCode =
NodeExists for /hadoop-ha/hacluster/ActiveStandbyElectorLock |
org.apache.zookeeper.server.PrepRequestProcessor.pRequest(PrepRequestProcessor.java:648)
*ZKFC Received :* ZK client
2015-04-15 21:24:54,237 | INFO | main-SendThread(160-149-0-114:24002) |
Socket connection established to 160-149-0-114/160.149.0.114:24002,
initiating session |
org.apache.zookeeper.ClientCnxn$SendThread.primeConnection(ClientCnxn.java:854)
2015-04-15 21:24:54,257 | INFO | main-SendThread(160-149-0-114:24002) |
Session establishment complete on server 160-149-0-114/160.149.0.114:24002,
*{color:blue}sessionid = 0x144cb2b3e4b36ae4 {color}* , negotiated timeout =
45000 |
org.apache.zookeeper.ClientCnxn$SendThread.onConnected(ClientCnxn.java:1259)
2015-04-15 21:24:54,260 | INFO | main-EventThread | EventThread shut down |
org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:512)
2015-04-15 21:24:54,262 | INFO | main-EventThread | Session connected. |
org.apache.hadoop.ha.ActiveStandbyElector.processWatchEvent(ActiveStandbyElector.java:547)
2015-04-15 21:24:54,264 | INFO | main-EventThread | Successfully
authenticated to ZooKeeper using SASL. |
org.apache.hadoop.ha.ActiveStandbyElector.processWatchEvent(ActiveStandbyElector.java:573)
one bit corrupted..please check the following for same..
144cb2b3e4b36ae4=101000100110010110010101100100100101100110110101011100100
164cb2b3e4b36ae4=101100100110010110010101100100100101100110110101011100100
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Re: Review Request 33713: ZOOKEEPER-2163 - Complete implementation and doc
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/33713/ --- (Updated April 30, 2015, 3:58 p.m.) Review request for zookeeper. Summary (updated) - ZOOKEEPER-2163 - Complete implementation and doc Bugs: ZOOKEEPER-2163 https://issues.apache.org/jira/browse/ZOOKEEPER-2163 Repository: zookeeper-git Description --- Introduce new ZNode type: container Diffs - CHANGES.txt 51ec65d bin/zkServer.sh dae3ce2 src/docs/src/documentation/content/xdocs/zookeeperAdmin.xml c12c2ca src/docs/src/documentation/content/xdocs/zookeeperProgrammers.xml 223cf8e src/java/main/org/apache/zookeeper/ZooDefs.java a4fc331 src/java/main/org/apache/zookeeper/ZooKeeper.java dd8ecf4 src/java/main/org/apache/zookeeper/server/ContainerManager.java PRE-CREATION src/java/main/org/apache/zookeeper/server/DataNode.java b341a69 src/java/main/org/apache/zookeeper/server/DataTree.java 78cddb1 src/java/main/org/apache/zookeeper/server/FinalRequestProcessor.java 7e3c29f src/java/main/org/apache/zookeeper/server/PrepRequestProcessor.java 4911acf src/java/main/org/apache/zookeeper/server/Request.java bed9b13 src/java/main/org/apache/zookeeper/server/TraceFormatter.java 582383d src/java/main/org/apache/zookeeper/server/ZooKeeperServerMain.java 63daea0 src/java/main/org/apache/zookeeper/server/quorum/CommitProcessor.java cf0900b src/java/main/org/apache/zookeeper/server/quorum/FollowerRequestProcessor.java 4d061f4 src/java/main/org/apache/zookeeper/server/quorum/LeaderZooKeeperServer.java 6434d02 src/java/main/org/apache/zookeeper/server/quorum/ObserverRequestProcessor.java 36a23ee src/java/main/org/apache/zookeeper/server/quorum/ReadOnlyRequestProcessor.java a49319c src/java/main/org/apache/zookeeper/server/util/SerializeUtils.java 1a45c5e src/java/test/org/apache/zookeeper/server/CreateContainerTest.java PRE-CREATION src/zookeeper.jute 709e935 Diff: https://reviews.apache.org/r/33713/diff/ Testing --- Thanks, Jordan Zimmerman
[jira] [Commented] (ZOOKEEPER-2171) avoid reverse lookups in QuorumCnxManager
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14521630#comment-14521630 ] Raul Gutierrez Segales commented on ZOOKEEPER-2171: --- done - thanks [~rakeshr]! avoid reverse lookups in QuorumCnxManager - Key: ZOOKEEPER-2171 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2171 Project: ZooKeeper Issue Type: Bug Components: quorum Reporter: Raul Gutierrez Segales Assignee: Raul Gutierrez Segales Fix For: 3.5.1, 3.6.0 Attachments: ZOOKEEPER-2171.patch, ZOOKEEPER-2171.patch, ZOOKEEPER-2171.patch Apparently, ZOOKEEPER-107 (via a quick git-blame look) introduced a bunch of getHostName() calls in QCM. Besides the overhead, these can cause problems when mixed with failing/mis-configured DNS servers. It would be nice to reduce them, if that doesn't affect operational correctness. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (ZOOKEEPER-2171) avoid reverse lookups in QuorumCnxManager
[ https://issues.apache.org/jira/browse/ZOOKEEPER-2171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14521731#comment-14521731 ] Hadoop QA commented on ZOOKEEPER-2171: -- -1 overall. Here are the results of testing the latest attachment http://issues.apache.org/jira/secure/attachment/12729463/ZOOKEEPER-2171.patch against trunk revision 1676359. +1 @author. The patch does not contain any @author tags. +1 tests included. The patch appears to include 11 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 2.0.3) warnings. +1 release audit. The applied patch does not increase the total number of release audit warnings. -1 core tests. The patch failed core unit tests. +1 contrib tests. The patch passed contrib unit tests. Test results: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/2659//testReport/ Findbugs warnings: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/2659//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html Console output: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/2659//console This message is automatically generated. avoid reverse lookups in QuorumCnxManager - Key: ZOOKEEPER-2171 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2171 Project: ZooKeeper Issue Type: Bug Components: quorum Reporter: Raul Gutierrez Segales Assignee: Raul Gutierrez Segales Fix For: 3.5.1, 3.6.0 Attachments: ZOOKEEPER-2171.patch, ZOOKEEPER-2171.patch, ZOOKEEPER-2171.patch Apparently, ZOOKEEPER-107 (via a quick git-blame look) introduced a bunch of getHostName() calls in QCM. Besides the overhead, these can cause problems when mixed with failing/mis-configured DNS servers. It would be nice to reduce them, if that doesn't affect operational correctness. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Failed: ZOOKEEPER-2171 PreCommit Build #2659
Jira: https://issues.apache.org/jira/browse/ZOOKEEPER-2171 Build: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/2659/ ### ## LAST 60 LINES OF THE CONSOLE ### [...truncated 365623 lines...] [exec] [exec] +1 @author. The patch does not contain any @author tags. [exec] [exec] +1 tests included. The patch appears to include 11 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 2.0.3) 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 failed 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/2659//testReport/ [exec] Findbugs warnings: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/2659//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html [exec] Console output: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/2659//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] ab0bb9b48b440a8e13404f97895bb4ead50c13f3 logged out [exec] [exec] [exec] == [exec] == [exec] Finished build. [exec] == [exec] == [exec] [exec] BUILD FAILED /home/jenkins/jenkins-slave/workspace/PreCommit-ZOOKEEPER-Build/trunk/build.xml:1721: exec returned: 1 Total time: 48 minutes 2 seconds Build step 'Execute shell' marked build as failure Archiving artifacts Sending artifact delta relative to PreCommit-ZOOKEEPER-Build #2654 Archived 7 artifacts Archive block size is 32768 Received 2 blocks and 497097 bytes Compression is 11.6% Took 14 sec Recording test results Description set: ZOOKEEPER-2171 Email was triggered for: Failure Sending email for trigger: Failure ### ## FAILED TESTS (if any) ## 1 tests failed. REGRESSION: org.apache.zookeeper.server.quorum.ReconfigRecoveryTest.testCurrentObserverIsParticipantInNewConfig Error Message: waiting for server 2 being up Stack Trace: junit.framework.AssertionFailedError: waiting for server 2 being up at org.apache.zookeeper.server.quorum.ReconfigRecoveryTest.testCurrentObserverIsParticipantInNewConfig(ReconfigRecoveryTest.java:529) at org.apache.zookeeper.JUnit4ZKTestRunner$LoggedInvokeMethod.evaluate(JUnit4ZKTestRunner.java:52)
