[jira] [Commented] (ZOOKEEPER-2362) ZooKeeper multi / transaction allows partial read

[Patrick Hunt (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-2362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15135094#comment-15135094
 ] 

Patrick Hunt commented on ZOOKEEPER-2362:
-

According to the thread this is ZK 3.4.6/Curator 2.8.0.

It would be great if you could provide a reproducible test case? We'd 
incorporate it into the patch. Also would help verify the logic.

> ZooKeeper multi / transaction allows partial read
> -
>
> Key: ZOOKEEPER-2362
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2362
> Project: ZooKeeper
>  Issue Type: Bug
>  Components: server
>Affects Versions: 3.4.6
>Reporter: Whitney Sorenson
>Priority: Critical
> Fix For: 3.4.9, 3.5.2
>
>
> In this thread 
> http://mail-archives.apache.org/mod_mbox/zookeeper-user/201602.mbox/%3CCAPbqGzicBkLLyVDm7RFM20z0y3X1v1P-C9-1%3D%3D1DDqRDTzdOmQ%40mail.gmail.com%3E
>  , I discussed an issue I've now seen in multiple environments:
> In a multi (using Curator), I write 2 new nodes. At some point, I issue 2 
> reads for these new nodes. In one read, I see one of the new nodes. In a 
> subsequent read, I fail to see the other new node:
> 1. Starting state : { /foo = , /bar =  }
> 2. In a multi, write: { /foo = A, /bar = B}
> 3. Read /foo as A
> 4. Read /bar as  
> #3 and #4 are issued 100% sequentially.
> It is not known at what point during #2, #3 starts.
> Note: the reads are getChildren() calls.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (ZOOKEEPER-2014) Only admin should be allowed to reconfig a cluster

[Patrick Hunt (JIRA)]

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

Patrick Hunt updated ZOOKEEPER-2014:

Fix Version/s: 3.5.2

> Only admin should be allowed to reconfig a cluster
> --
>
> Key: ZOOKEEPER-2014
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2014
> Project: ZooKeeper
>  Issue Type: Bug
>  Components: server
>Affects Versions: 3.5.0
>Reporter: Raul Gutierrez Segales
>Assignee: Raul Gutierrez Segales
>Priority: Blocker
> Fix For: 3.5.2
>
> Attachments: ZOOKEEPER-2014.patch
>
>
> ZOOKEEPER-107 introduces reconfiguration support via the reconfig() call. We 
> should, at the very least, ensure that only the Admin can reconfigure a 
> cluster. Perhaps restricting access to /zookeeper/config as well, though this 
> is debatable. Surely one could ensure Admin only access via an ACL, but that 
> would leave everyone who doesn't use ACLs unprotected. We could also force a 
> default ACL to make it a bit more consistent (maybe).
> Finally, making reconfig() only available to Admins means they have to run 
> with zookeeper.DigestAuthenticationProvider.superDigest (which I am not sure 
> if everyone does, or how would it work with other authentication providers). 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (ZOOKEEPER-2314) Improve SASL documentation

[Patrick Hunt (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-2314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15135164#comment-15135164
 ] 

Patrick Hunt commented on ZOOKEEPER-2314:
-

Is this really a blocker? Or lesser priority? Additionally should it block 
3.4.8?

> Improve SASL documentation
> --
>
> Key: ZOOKEEPER-2314
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2314
> Project: ZooKeeper
>  Issue Type: Improvement
>  Components: documentation
>Affects Versions: 3.4.6, 3.5.1
>Reporter: Flavio Junqueira
>Assignee: Flavio Junqueira
>Priority: Blocker
> Fix For: 3.4.8, 3.5.2, 3.6.0
>
>
> Points that occur to me right now:
> # The login object in ZooKeeperSaslClient is static, which means that if you 
> try to create another client for tests, the login object will be the first 
> one you've set for all runs. I've experienced this with 3.4.6.
> # There are a number of properties spread across the code that do not appear 
> in the docs. For example, zookeeper.allowSaslFailedClients isn't documented 
> afaict.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (ZOOKEEPER-2314) Improve SASL documentation

[Raul Gutierrez Segales (JIRA)]

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

Raul Gutierrez Segales updated ZOOKEEPER-2314:
--
Fix Version/s: (was: 3.4.8)
   3.4.9

> Improve SASL documentation
> --
>
> Key: ZOOKEEPER-2314
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2314
> Project: ZooKeeper
>  Issue Type: Improvement
>  Components: documentation
>Affects Versions: 3.4.6, 3.5.1
>Reporter: Flavio Junqueira
>Assignee: Flavio Junqueira
>Priority: Blocker
> Fix For: 3.4.9, 3.5.2, 3.6.0
>
>
> Points that occur to me right now:
> # The login object in ZooKeeperSaslClient is static, which means that if you 
> try to create another client for tests, the login object will be the first 
> one you've set for all runs. I've experienced this with 3.4.6.
> # There are a number of properties spread across the code that do not appear 
> in the docs. For example, zookeeper.allowSaslFailedClients isn't documented 
> afaict.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (ZOOKEEPER-2363) DatadirCleanupManager never created by ZookeeperServerMain

[David Foregger (JIRA)]

David Foregger created ZOOKEEPER-2363:
-

 Summary: DatadirCleanupManager never created by ZookeeperServerMain
 Key: ZOOKEEPER-2363
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2363
 Project: ZooKeeper
  Issue Type: Bug
Affects Versions: 3.4.0
Reporter: David Foregger


h4. Background
ZOOKEEPER-1107 introduced a DatadirCleanupManager to automatically purge 
snapshots. This can be configured using autopurge.snapRetainCount and 
autopurge.purgeInterval. This is documented 
[here|http://zookeeper.apache.org/doc/r3.4.5/zookeeperAdmin.html#Ongoing+Data+Directory+Cleanup]
 and 
[there|http://zookeeper.apache.org/doc/r3.4.5/zookeeperAdmin.html#sc_advancedConfiguration].
h4. Symptoms
Autopurging does not work when running a standalone ZooKeeperServer. The 
DatadirCleanupManager is started by the QuorumPeerMain, but there is no similar 
setup ZooKeeperServerMain. ServerConfig does not hold autopurge properties.
h4. Expected Behavior
Starting a standalone zookeeper server should enable autopurging with the same 
behavior as a quorum server. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (ZOOKEEPER-2362) ZooKeeper multi / transaction allows partial read

[Whitney Sorenson (JIRA)]

Whitney Sorenson created ZOOKEEPER-2362:
---

 Summary: ZooKeeper multi / transaction allows partial read
 Key: ZOOKEEPER-2362
 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2362
 Project: ZooKeeper
  Issue Type: Bug
Reporter: Whitney Sorenson
Priority: Critical


In this thread 
http://mail-archives.apache.org/mod_mbox/zookeeper-user/201602.mbox/%3CCAPbqGzicBkLLyVDm7RFM20z0y3X1v1P-C9-1%3D%3D1DDqRDTzdOmQ%40mail.gmail.com%3E
 , I discussed an issue I've now seen in multiple environments:

In a multi (using Curator), I write 2 new nodes. At some point, I issue 2 reads 
for these new nodes. In one read, I see one of the new nodes. In a subsequent 
read, I fail to see the other new node:

1. Starting state : { /foo = , /bar =  }
2. In a multi, write: { /foo = A, /bar = B}
3. Read /foo as A
4. Read /bar as  

#3 and #4 are issued 100% sequentially.

It is not known at what point during #2, #3 starts.

Note: the reads are getChildren() calls.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (ZOOKEEPER-2345) ServerCnxnFactory.configureSaslLogin() loses stack trace on auth failures

[Jeremy Custenborder (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-2345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15134725#comment-15134725
 ] 

Jeremy Custenborder commented on ZOOKEEPER-2345:


I've bumped into this a couple times recently so I'll add some troubleshooting 
information for anyone who arrives here via a search for the exception.
h4. Verify DNS
The machine must be able to resolve it's own hostname to the hostname that 
other machines will connect to. Verify the hosts file is setup correctly.
h4. Verify the format of your jaas file 
The principal needs to be to the fully qualified hostname
{code}
Server {
  com.sun.security.auth.module.Krb5LoginModule required
  useKeyTab=true
  keyTab="/etc/security/keytabs/zookeeper.keytab"
  storeKey=true
  useTicketCache=false
  principal="zookeeper/zookeeper.example@example.com";
};
{code}
h4. Make sure you can kinit with the contents of your jaas file
If possible you should try to do this with the local user zookeeper will be 
running as. 
{code}
kinit -kt  
{code}
This should return successfully without prompting for a password.
h4. Make sure your jaas file and keytab are readable by the zookeeper user
{code}
ls -la 
-r--r-. 1 zookeeper zookeeper 4198 Feb  3 19:32 
/etc/security/keytabs/zookeeper.keytab
{code}
If the permissions are not correct use this.
{code}
chmod 0440 /etc/security/keytabs/zookeeper.keytab
{code}
h4. Verify you have the proper JCE policy files (Oracle JRE)
If you are using the Oracle JRE and strong encryption like 
aes256-cts-hmac-sha1-96 or aes128-cts-hmac-sha1-96, additional policy jars need 
to be installed. Download the JCE jars for [Java 
7|http://www.oracle.com/technetwork/java/javase/downloads/jce-7-download-432124.html]
 or [Java 
8|http://www.oracle.com/technetwork/java/javase/downloads/jce8-download-2133166.html]

> ServerCnxnFactory.configureSaslLogin() loses stack trace on auth failures
> -
>
> Key: ZOOKEEPER-2345
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2345
> Project: ZooKeeper
>  Issue Type: Sub-task
>  Components: server
>Affects Versions: 3.4.6
>Reporter: Steve Loughran
>
> When there's a problem authenticating in 
> {{ServerCnxnFactory.configureSaslLogin() }}, the exception is retained -but 
> the full stack lost.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (ZOOKEEPER-830) forrest docs for read-only mode

[Jason Rosenberg (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-830?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15134536#comment-15134536
 ] 

Jason Rosenberg commented on ZOOKEEPER-830:
---

Is there a reason this ticket has not been resolved?

> forrest docs for read-only mode
> ---
>
> Key: ZOOKEEPER-830
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-830
> Project: ZooKeeper
>  Issue Type: Sub-task
>Reporter: Sergey Doroshenko
>Assignee: Sergey Doroshenko
> Attachments: ZOOKEEPER-830.patch, ZOOKEEPER-830.patch
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (ZOOKEEPER-2345) ServerCnxnFactory.configureSaslLogin() loses stack trace on auth failures

[Steve Loughran (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-2345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15134839#comment-15134839
 ] 

Steve Loughran commented on ZOOKEEPER-2345:
---

good summary of tactics.

If you have a look at HADOOP-12426, we've a new class, KDiag, to go into Hadoop 
core to do a big chunk of this diagnostics. Though not looking in the JAAS file 
to extract its principal -nice idea. Network diagnostics is something we should 
do too, probably initially independently.

The KDiag patch has yet to go in/get much public review —if you do hit kerberos 
problems, then try and let us know how you got on.  And any extra diagnostics 
you can add will be most welcome.

> ServerCnxnFactory.configureSaslLogin() loses stack trace on auth failures
> -
>
> Key: ZOOKEEPER-2345
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2345
> Project: ZooKeeper
>  Issue Type: Sub-task
>  Components: server
>Affects Versions: 3.4.6
>Reporter: Steve Loughran
>
> When there's a problem authenticating in 
> {{ServerCnxnFactory.configureSaslLogin() }}, the exception is retained -but 
> the full stack lost.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (ZOOKEEPER-2362) ZooKeeper multi / transaction allows partial read

[Patrick Hunt (JIRA)]

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

Patrick Hunt updated ZOOKEEPER-2362:

Affects Version/s: 3.4.6

> ZooKeeper multi / transaction allows partial read
> -
>
> Key: ZOOKEEPER-2362
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2362
> Project: ZooKeeper
>  Issue Type: Bug
>Affects Versions: 3.4.6
>Reporter: Whitney Sorenson
>Priority: Critical
>
> In this thread 
> http://mail-archives.apache.org/mod_mbox/zookeeper-user/201602.mbox/%3CCAPbqGzicBkLLyVDm7RFM20z0y3X1v1P-C9-1%3D%3D1DDqRDTzdOmQ%40mail.gmail.com%3E
>  , I discussed an issue I've now seen in multiple environments:
> In a multi (using Curator), I write 2 new nodes. At some point, I issue 2 
> reads for these new nodes. In one read, I see one of the new nodes. In a 
> subsequent read, I fail to see the other new node:
> 1. Starting state : { /foo = , /bar =  }
> 2. In a multi, write: { /foo = A, /bar = B}
> 3. Read /foo as A
> 4. Read /bar as  
> #3 and #4 are issued 100% sequentially.
> It is not known at what point during #2, #3 starts.
> Note: the reads are getChildren() calls.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (ZOOKEEPER-2362) ZooKeeper multi / transaction allows partial read

[Patrick Hunt (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-2362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15135104#comment-15135104
 ] 

Patrick Hunt commented on ZOOKEEPER-2362:
-

What is the ensemble size and are you attached to the leader or a follower when 
this happens? You might also turn on debug logging and see if that provides any 
insight. Attaching the logs here could get more eyes on it.

> ZooKeeper multi / transaction allows partial read
> -
>
> Key: ZOOKEEPER-2362
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2362
> Project: ZooKeeper
>  Issue Type: Bug
>  Components: server
>Affects Versions: 3.4.6
>Reporter: Whitney Sorenson
>Priority: Critical
> Fix For: 3.4.9, 3.5.2
>
>
> In this thread 
> http://mail-archives.apache.org/mod_mbox/zookeeper-user/201602.mbox/%3CCAPbqGzicBkLLyVDm7RFM20z0y3X1v1P-C9-1%3D%3D1DDqRDTzdOmQ%40mail.gmail.com%3E
>  , I discussed an issue I've now seen in multiple environments:
> In a multi (using Curator), I write 2 new nodes. At some point, I issue 2 
> reads for these new nodes. In one read, I see one of the new nodes. In a 
> subsequent read, I fail to see the other new node:
> 1. Starting state : { /foo = , /bar =  }
> 2. In a multi, write: { /foo = A, /bar = B}
> 3. Read /foo as A
> 4. Read /bar as  
> #3 and #4 are issued 100% sequentially.
> It is not known at what point during #2, #3 starts.
> Note: the reads are getChildren() calls.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (ZOOKEEPER-2314) Improve SASL documentation

[Raul Gutierrez Segales (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-2314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15135175#comment-15135175
 ] 

Raul Gutierrez Segales commented on ZOOKEEPER-2314:
---

Lets move it to 3.4.9, the spirit of 3.4.8 was to fix the shutdown issue in 
3.4.7. 

> Improve SASL documentation
> --
>
> Key: ZOOKEEPER-2314
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2314
> Project: ZooKeeper
>  Issue Type: Improvement
>  Components: documentation
>Affects Versions: 3.4.6, 3.5.1
>Reporter: Flavio Junqueira
>Assignee: Flavio Junqueira
>Priority: Blocker
> Fix For: 3.4.8, 3.5.2, 3.6.0
>
>
> Points that occur to me right now:
> # The login object in ZooKeeperSaslClient is static, which means that if you 
> try to create another client for tests, the login object will be the first 
> one you've set for all runs. I've experienced this with 3.4.6.
> # There are a number of properties spread across the code that do not appear 
> in the docs. For example, zookeeper.allowSaslFailedClients isn't documented 
> afaict.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (ZOOKEEPER-2362) ZooKeeper multi / transaction allows partial read

[Patrick Hunt (JIRA)]

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

Patrick Hunt updated ZOOKEEPER-2362:

Fix Version/s: 3.5.2
   3.4.9

> ZooKeeper multi / transaction allows partial read
> -
>
> Key: ZOOKEEPER-2362
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2362
> Project: ZooKeeper
>  Issue Type: Bug
>  Components: server
>Affects Versions: 3.4.6
>Reporter: Whitney Sorenson
>Priority: Critical
> Fix For: 3.4.9, 3.5.2
>
>
> In this thread 
> http://mail-archives.apache.org/mod_mbox/zookeeper-user/201602.mbox/%3CCAPbqGzicBkLLyVDm7RFM20z0y3X1v1P-C9-1%3D%3D1DDqRDTzdOmQ%40mail.gmail.com%3E
>  , I discussed an issue I've now seen in multiple environments:
> In a multi (using Curator), I write 2 new nodes. At some point, I issue 2 
> reads for these new nodes. In one read, I see one of the new nodes. In a 
> subsequent read, I fail to see the other new node:
> 1. Starting state : { /foo = , /bar =  }
> 2. In a multi, write: { /foo = A, /bar = B}
> 3. Read /foo as A
> 4. Read /bar as  
> #3 and #4 are issued 100% sequentially.
> It is not known at what point during #2, #3 starts.
> Note: the reads are getChildren() calls.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (ZOOKEEPER-2362) ZooKeeper multi / transaction allows partial read

[Patrick Hunt (JIRA)]

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

Patrick Hunt updated ZOOKEEPER-2362:

Component/s: server

> ZooKeeper multi / transaction allows partial read
> -
>
> Key: ZOOKEEPER-2362
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2362
> Project: ZooKeeper
>  Issue Type: Bug
>  Components: server
>Affects Versions: 3.4.6
>Reporter: Whitney Sorenson
>Priority: Critical
> Fix For: 3.4.9, 3.5.2
>
>
> In this thread 
> http://mail-archives.apache.org/mod_mbox/zookeeper-user/201602.mbox/%3CCAPbqGzicBkLLyVDm7RFM20z0y3X1v1P-C9-1%3D%3D1DDqRDTzdOmQ%40mail.gmail.com%3E
>  , I discussed an issue I've now seen in multiple environments:
> In a multi (using Curator), I write 2 new nodes. At some point, I issue 2 
> reads for these new nodes. In one read, I see one of the new nodes. In a 
> subsequent read, I fail to see the other new node:
> 1. Starting state : { /foo = , /bar =  }
> 2. In a multi, write: { /foo = A, /bar = B}
> 3. Read /foo as A
> 4. Read /bar as  
> #3 and #4 are issued 100% sequentially.
> It is not known at what point during #2, #3 starts.
> Note: the reads are getChildren() calls.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (ZOOKEEPER-2345) ServerCnxnFactory.configureSaslLogin() loses stack trace on auth failures

[Steve Loughran (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-2345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15134852#comment-15134852
 ] 

Steve Loughran commented on ZOOKEEPER-2345:
---

+ linked to it from [the ZK section of the hadoop & kerberos 
ebook|https://steveloughran.gitbooks.io/kerberos_and_hadoop/content/sections/zookeeper.html]

> ServerCnxnFactory.configureSaslLogin() loses stack trace on auth failures
> -
>
> Key: ZOOKEEPER-2345
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2345
> Project: ZooKeeper
>  Issue Type: Sub-task
>  Components: server
>Affects Versions: 3.4.6
>Reporter: Steve Loughran
>
> When there's a problem authenticating in 
> {{ServerCnxnFactory.configureSaslLogin() }}, the exception is retained -but 
> the full stack lost.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (ZOOKEEPER-954) Findbugs/ClientCnxn: Bug type JLM_JSR166_UTILCONCURRENT_MONITORENTER

[Hiroshi Ikeda (JIRA)]

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

Hiroshi Ikeda updated ZOOKEEPER-954:

Attachment: ZOOKEEPER-954.patch

Added some patch to remove icky volatile fields and recklessly locking a 
concurrent collection.

> Findbugs/ClientCnxn: Bug type JLM_JSR166_UTILCONCURRENT_MONITORENTER
> 
>
> Key: ZOOKEEPER-954
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-954
> Project: ZooKeeper
>  Issue Type: Bug
>  Components: java client
>Reporter: Thomas Koch
>Priority: Minor
> Attachments: ZOOKEEPER-954.patch
>
>
> JLM   Synchronization performed on java.util.concurrent.LinkedBlockingQueue 
> in org.apache.zookeeper.ClientCnxn$EventThread.queuePacket(ClientCnxn$Packet)
>   
> Bug type JLM_JSR166_UTILCONCURRENT_MONITORENTER (click for details)
> In class org.apache.zookeeper.ClientCnxn$EventThread
> In method 
> org.apache.zookeeper.ClientCnxn$EventThread.queuePacket(ClientCnxn$Packet)
> Type java.util.concurrent.LinkedBlockingQueue
> Value loaded from field 
> org.apache.zookeeper.ClientCnxn$EventThread.waitingEvents
> At ClientCnxn.java:[line 411]
> JLM   Synchronization performed on java.util.concurrent.LinkedBlockingQueue 
> in org.apache.zookeeper.ClientCnxn$EventThread.run()
>   
> Bug type JLM_JSR166_UTILCONCURRENT_MONITORENTER (click for details)
> In class org.apache.zookeeper.ClientCnxn$EventThread
> In method org.apache.zookeeper.ClientCnxn$EventThread.run()
> Type java.util.concurrent.LinkedBlockingQueue
> Value loaded from field 
> org.apache.zookeeper.ClientCnxn$EventThread.waitingEvents
> At ClientCnxn.java:[line 436]
> The respective code:
> 409  public void queuePacket(Packet packet) {
> 410 if (wasKilled) {
> 411synchronized (waitingEvents) {
> 412   if (isRunning) waitingEvents.add(packet);
> 413   else processEvent(packet);
> 414}
> 415 } else {
> 416waitingEvents.add(packet);
> 417 }
> 418  }
> 419   
> 420   public void queueEventOfDeath() {
> 421   waitingEvents.add(eventOfDeath);
> 422   }
> 423   
> 424   @Override
> 425   public void run() {
> 426  try {
> 427 isRunning = true;
> 428 while (true) {
> 429Object event = waitingEvents.take();
> 430if (event == eventOfDeath) {
> 431   wasKilled = true;
> 432} else {
> 433   processEvent(event);
> 434}
> 435if (wasKilled)
> 436   synchronized (waitingEvents) {
> 437  if (waitingEvents.isEmpty()) {
> 438 isRunning = false;
> 439 break;
> 440  }
> 441   }
> 442 }



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (ZOOKEEPER-954) Findbugs/ClientCnxn: Bug type JLM_JSR166_UTILCONCURRENT_MONITORENTER

[Hiroshi Ikeda (JIRA)]

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

Hiroshi Ikeda updated ZOOKEEPER-954:

Attachment: ZOOKEEPER-954-V2.patch

Oops,  I should have stripped.

> Findbugs/ClientCnxn: Bug type JLM_JSR166_UTILCONCURRENT_MONITORENTER
> 
>
> Key: ZOOKEEPER-954
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-954
> Project: ZooKeeper
>  Issue Type: Bug
>  Components: java client
>Reporter: Thomas Koch
>Priority: Minor
> Attachments: ZOOKEEPER-954-V2.patch, ZOOKEEPER-954.patch
>
>
> JLM   Synchronization performed on java.util.concurrent.LinkedBlockingQueue 
> in org.apache.zookeeper.ClientCnxn$EventThread.queuePacket(ClientCnxn$Packet)
>   
> Bug type JLM_JSR166_UTILCONCURRENT_MONITORENTER (click for details)
> In class org.apache.zookeeper.ClientCnxn$EventThread
> In method 
> org.apache.zookeeper.ClientCnxn$EventThread.queuePacket(ClientCnxn$Packet)
> Type java.util.concurrent.LinkedBlockingQueue
> Value loaded from field 
> org.apache.zookeeper.ClientCnxn$EventThread.waitingEvents
> At ClientCnxn.java:[line 411]
> JLM   Synchronization performed on java.util.concurrent.LinkedBlockingQueue 
> in org.apache.zookeeper.ClientCnxn$EventThread.run()
>   
> Bug type JLM_JSR166_UTILCONCURRENT_MONITORENTER (click for details)
> In class org.apache.zookeeper.ClientCnxn$EventThread
> In method org.apache.zookeeper.ClientCnxn$EventThread.run()
> Type java.util.concurrent.LinkedBlockingQueue
> Value loaded from field 
> org.apache.zookeeper.ClientCnxn$EventThread.waitingEvents
> At ClientCnxn.java:[line 436]
> The respective code:
> 409  public void queuePacket(Packet packet) {
> 410 if (wasKilled) {
> 411synchronized (waitingEvents) {
> 412   if (isRunning) waitingEvents.add(packet);
> 413   else processEvent(packet);
> 414}
> 415 } else {
> 416waitingEvents.add(packet);
> 417 }
> 418  }
> 419   
> 420   public void queueEventOfDeath() {
> 421   waitingEvents.add(eventOfDeath);
> 422   }
> 423   
> 424   @Override
> 425   public void run() {
> 426  try {
> 427 isRunning = true;
> 428 while (true) {
> 429Object event = waitingEvents.take();
> 430if (event == eventOfDeath) {
> 431   wasKilled = true;
> 432} else {
> 433   processEvent(event);
> 434}
> 435if (wasKilled)
> 436   synchronized (waitingEvents) {
> 437  if (waitingEvents.isEmpty()) {
> 438 isRunning = false;
> 439 break;
> 440  }
> 441   }
> 442 }



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (ZOOKEEPER-954) Findbugs/ClientCnxn: Bug type JLM_JSR166_UTILCONCURRENT_MONITORENTER

[Hadoop QA (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15133950#comment-15133950
 ] 

Hadoop QA commented on ZOOKEEPER-954:
-

-1 overall.  Here are the results of testing the latest attachment 
  http://issues.apache.org/jira/secure/attachment/12786452/ZOOKEEPER-954.patch
  against trunk revision 1728577.

+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/3034//console

This message is automatically generated.

> Findbugs/ClientCnxn: Bug type JLM_JSR166_UTILCONCURRENT_MONITORENTER
> 
>
> Key: ZOOKEEPER-954
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-954
> Project: ZooKeeper
>  Issue Type: Bug
>  Components: java client
>Reporter: Thomas Koch
>Priority: Minor
> Attachments: ZOOKEEPER-954.patch
>
>
> JLM   Synchronization performed on java.util.concurrent.LinkedBlockingQueue 
> in org.apache.zookeeper.ClientCnxn$EventThread.queuePacket(ClientCnxn$Packet)
>   
> Bug type JLM_JSR166_UTILCONCURRENT_MONITORENTER (click for details)
> In class org.apache.zookeeper.ClientCnxn$EventThread
> In method 
> org.apache.zookeeper.ClientCnxn$EventThread.queuePacket(ClientCnxn$Packet)
> Type java.util.concurrent.LinkedBlockingQueue
> Value loaded from field 
> org.apache.zookeeper.ClientCnxn$EventThread.waitingEvents
> At ClientCnxn.java:[line 411]
> JLM   Synchronization performed on java.util.concurrent.LinkedBlockingQueue 
> in org.apache.zookeeper.ClientCnxn$EventThread.run()
>   
> Bug type JLM_JSR166_UTILCONCURRENT_MONITORENTER (click for details)
> In class org.apache.zookeeper.ClientCnxn$EventThread
> In method org.apache.zookeeper.ClientCnxn$EventThread.run()
> Type java.util.concurrent.LinkedBlockingQueue
> Value loaded from field 
> org.apache.zookeeper.ClientCnxn$EventThread.waitingEvents
> At ClientCnxn.java:[line 436]
> The respective code:
> 409  public void queuePacket(Packet packet) {
> 410 if (wasKilled) {
> 411synchronized (waitingEvents) {
> 412   if (isRunning) waitingEvents.add(packet);
> 413   else processEvent(packet);
> 414}
> 415 } else {
> 416waitingEvents.add(packet);
> 417 }
> 418  }
> 419   
> 420   public void queueEventOfDeath() {
> 421   waitingEvents.add(eventOfDeath);
> 422   }
> 423   
> 424   @Override
> 425   public void run() {
> 426  try {
> 427 isRunning = true;
> 428 while (true) {
> 429Object event = waitingEvents.take();
> 430if (event == eventOfDeath) {
> 431   wasKilled = true;
> 432} else {
> 433   processEvent(event);
> 434}
> 435if (wasKilled)
> 436   synchronized (waitingEvents) {
> 437  if (waitingEvents.isEmpty()) {
> 438 isRunning = false;
> 439 break;
> 440  }
> 441   }
> 442 }



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Failed: ZOOKEEPER-954 PreCommit Build #3034

[Apache Jenkins Server]

Jira: https://issues.apache.org/jira/browse/ZOOKEEPER-954
Build: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/3034/

###
## LAST 60 LINES OF THE CONSOLE 
###
[...truncated 104 lines...]
 [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/12786452/ZOOKEEPER-954.patch
 [exec]   against trunk revision 1728577.
 [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/3034//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] b27d6365fc04ae3516d8c40ab7a628259e24c70c 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:1816:
 exec returned: 1

Total time: 1 minute 19 seconds
Build step 'Execute shell' marked build as failure
Archiving artifacts
Setting 
LATEST1_7_HOME=/home/jenkins/jenkins-slave/tools/hudson.model.JDK/latest1.7
Recording test results
Setting 
LATEST1_7_HOME=/home/jenkins/jenkins-slave/tools/hudson.model.JDK/latest1.7
ERROR: Publisher 'Publish JUnit test result report' failed: No test report 
files were found. Configuration error?
Setting 
LATEST1_7_HOME=/home/jenkins/jenkins-slave/tools/hudson.model.JDK/latest1.7
[description-setter] Description set: ZOOKEEPER-954
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any
Setting 
LATEST1_7_HOME=/home/jenkins/jenkins-slave/tools/hudson.model.JDK/latest1.7
Setting 
LATEST1_7_HOME=/home/jenkins/jenkins-slave/tools/hudson.model.JDK/latest1.7
Setting 
LATEST1_7_HOME=/home/jenkins/jenkins-slave/tools/hudson.model.JDK/latest1.7
Setting 
LATEST1_7_HOME=/home/jenkins/jenkins-slave/tools/hudson.model.JDK/latest1.7



###
## FAILED TESTS (if any) 
##
No tests ran.

[jira] [Commented] (ZOOKEEPER-1356) Avoid permanent caching of server IPs in the client

[Brice Dutheil (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-1356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15133918#comment-15133918
 ] 

Brice Dutheil commented on ZOOKEEPER-1356:
--

It seems so.

I'm looking forward the release of 3.4.8 by the way ;P
Which would greatly simply the deployment on docker container.

> Avoid permanent caching of server IPs in the client 
> 
>
> Key: ZOOKEEPER-1356
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1356
> Project: ZooKeeper
>  Issue Type: Bug
>  Components: java client
>Affects Versions: 3.3.4, 3.4.2
>Reporter: Neha Narkhede
>Assignee: Neha Narkhede
>
> Relevant conversation on the dev mailing list - 
> https://email.corp.linkedin.com/owa/redir.aspx?C=87f3d1e78c96438c8115e450f410d010=http%3a%2f%2fmarkmail.org%2fmessage%2f3vzynx6rgurubf3p%3fq%3dPerforming%2bno%2bdowntime%2bhardware%2bchanges%2bto%2ba%2blive%2bzookeeper%2bcluster%2blist%3aorg%252Eapache%252Ehadoop%252Ezookeeper-dev
> Basically, the client caches the list of server IPs internally and maintains 
> that list for the entire lifetime of the client. This limits the ability to 
> remove/change a server node from a zookeeper cluster, without having to 
> restart every client. Also, two levels of IP caching, one in the JVM and one 
> in the zookeeper client code seems unnecessar.
> It would be ideal to provide a config option that would turn off this IP 
> caching in the client and re-resolve the host names during the reconnect. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Failed: ZOOKEEPER-954 PreCommit Build #3035

[Apache Jenkins Server]

Jira: https://issues.apache.org/jira/browse/ZOOKEEPER-954
Build: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/3035/

###
## LAST 60 LINES OF THE CONSOLE 
###
[...truncated 368967 lines...]
 [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 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/3035//testReport/
 [exec] Findbugs warnings: 
https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/3035//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html
 [exec] Console output: 
https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/3035//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] cfe8fc7b5ee3529ccdfe4fa6a4d635af9e530a94 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:1816:
 exec returned: 2

Total time: 13 minutes 40 seconds
Build step 'Execute shell' marked build as failure
Archiving artifacts
Setting 
LATEST1_7_HOME=/home/jenkins/jenkins-slave/tools/hudson.model.JDK/latest1.7
Recording test results
Setting 
LATEST1_7_HOME=/home/jenkins/jenkins-slave/tools/hudson.model.JDK/latest1.7
Setting 
LATEST1_7_HOME=/home/jenkins/jenkins-slave/tools/hudson.model.JDK/latest1.7
[description-setter] Description set: ZOOKEEPER-954
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any
Setting 
LATEST1_7_HOME=/home/jenkins/jenkins-slave/tools/hudson.model.JDK/latest1.7
Setting 
LATEST1_7_HOME=/home/jenkins/jenkins-slave/tools/hudson.model.JDK/latest1.7
Setting 
LATEST1_7_HOME=/home/jenkins/jenkins-slave/tools/hudson.model.JDK/latest1.7
Setting 
LATEST1_7_HOME=/home/jenkins/jenkins-slave/tools/hudson.model.JDK/latest1.7



###
## FAILED TESTS (if any) 
##
All tests passed

[jira] [Commented] (ZOOKEEPER-954) Findbugs/ClientCnxn: Bug type JLM_JSR166_UTILCONCURRENT_MONITORENTER

[Hadoop QA (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15133993#comment-15133993
 ] 

Hadoop QA commented on ZOOKEEPER-954:
-

-1 overall.  Here are the results of testing the latest attachment 
  
http://issues.apache.org/jira/secure/attachment/12786453/ZOOKEEPER-954-V2.patch
  against trunk revision 1728577.

+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 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/3035//testReport/
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/3035//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html
Console output: 
https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/3035//console

This message is automatically generated.

> Findbugs/ClientCnxn: Bug type JLM_JSR166_UTILCONCURRENT_MONITORENTER
> 
>
> Key: ZOOKEEPER-954
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-954
> Project: ZooKeeper
>  Issue Type: Bug
>  Components: java client
>Reporter: Thomas Koch
>Priority: Minor
> Attachments: ZOOKEEPER-954-V2.patch, ZOOKEEPER-954.patch
>
>
> JLM   Synchronization performed on java.util.concurrent.LinkedBlockingQueue 
> in org.apache.zookeeper.ClientCnxn$EventThread.queuePacket(ClientCnxn$Packet)
>   
> Bug type JLM_JSR166_UTILCONCURRENT_MONITORENTER (click for details)
> In class org.apache.zookeeper.ClientCnxn$EventThread
> In method 
> org.apache.zookeeper.ClientCnxn$EventThread.queuePacket(ClientCnxn$Packet)
> Type java.util.concurrent.LinkedBlockingQueue
> Value loaded from field 
> org.apache.zookeeper.ClientCnxn$EventThread.waitingEvents
> At ClientCnxn.java:[line 411]
> JLM   Synchronization performed on java.util.concurrent.LinkedBlockingQueue 
> in org.apache.zookeeper.ClientCnxn$EventThread.run()
>   
> Bug type JLM_JSR166_UTILCONCURRENT_MONITORENTER (click for details)
> In class org.apache.zookeeper.ClientCnxn$EventThread
> In method org.apache.zookeeper.ClientCnxn$EventThread.run()
> Type java.util.concurrent.LinkedBlockingQueue
> Value loaded from field 
> org.apache.zookeeper.ClientCnxn$EventThread.waitingEvents
> At ClientCnxn.java:[line 436]
> The respective code:
> 409  public void queuePacket(Packet packet) {
> 410 if (wasKilled) {
> 411synchronized (waitingEvents) {
> 412   if (isRunning) waitingEvents.add(packet);
> 413   else processEvent(packet);
> 414}
> 415 } else {
> 416waitingEvents.add(packet);
> 417 }
> 418  }
> 419   
> 420   public void queueEventOfDeath() {
> 421   waitingEvents.add(eventOfDeath);
> 422   }
> 423   
> 424   @Override
> 425   public void run() {
> 426  try {
> 427 isRunning = true;
> 428 while (true) {
> 429Object event = waitingEvents.take();
> 430if (event == eventOfDeath) {
> 431   wasKilled = true;
> 432} else {
> 433   processEvent(event);
> 434}
> 435if (wasKilled)
> 436   synchronized (waitingEvents) {
> 437  if (waitingEvents.isEmpty()) {
> 438 isRunning = false;
> 439 break;
> 440  }
> 441   }
> 442 }



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (ZOOKEEPER-2358) NettyServerCnxn leaks watches upon close

[Raul Gutierrez Segales (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-2358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15135484#comment-15135484
 ] 

Raul Gutierrez Segales commented on ZOOKEEPER-2358:
---

[~fpj], [~iandi]: punting this for 3.4.9 (but do ping me when this is ready for 
review). 

> NettyServerCnxn leaks watches upon close
> 
>
> Key: ZOOKEEPER-2358
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2358
> Project: ZooKeeper
>  Issue Type: Bug
>Affects Versions: 3.4.7, 3.5.1
>Reporter: Ian Dimayuga
>Assignee: Ian Dimayuga
> Fix For: 3.4.9, 3.5.2
>
> Attachments: ZOOKEEPER-2358-3.4.patch, ZOOKEEPER-2358.patch
>
>
> NettyServerCnxn.close() neglects to call zkServer.removeCnxn the way 
> NIOServerCnxn.close() does. Also, WatchLeakTest does not test watch leaks in 
> Netty.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (ZOOKEEPER-2358) NettyServerCnxn leaks watches upon close

[Raul Gutierrez Segales (JIRA)]

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

Raul Gutierrez Segales updated ZOOKEEPER-2358:
--
Fix Version/s: (was: 3.4.8)
   3.4.9

> NettyServerCnxn leaks watches upon close
> 
>
> Key: ZOOKEEPER-2358
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2358
> Project: ZooKeeper
>  Issue Type: Bug
>Affects Versions: 3.4.7, 3.5.1
>Reporter: Ian Dimayuga
>Assignee: Ian Dimayuga
> Fix For: 3.4.9, 3.5.2
>
> Attachments: ZOOKEEPER-2358-3.4.patch, ZOOKEEPER-2358.patch
>
>
> NettyServerCnxn.close() neglects to call zkServer.removeCnxn the way 
> NIOServerCnxn.close() does. Also, WatchLeakTest does not test watch leaks in 
> Netty.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (ZOOKEEPER-2344) Provide more diagnostics/stack traces on SASL Auth failure

[Raul Gutierrez Segales (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-2344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15135488#comment-15135488
 ] 

Raul Gutierrez Segales commented on ZOOKEEPER-2344:
---

[~cnauroth], [~steve_l]: lets target this for 3.4.9 - thanks!

> Provide more diagnostics/stack traces on SASL Auth failure
> --
>
> Key: ZOOKEEPER-2344
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2344
> Project: ZooKeeper
>  Issue Type: Improvement
>  Components: java client, server
>Affects Versions: 3.4.7, 3.5.1
>Reporter: Steve Loughran
> Fix For: 3.4.9, 3.5.2, 3.6.0
>
>
> When Kerberos decides it doesn't want to work, the JRE libraries provide some 
> terse and unhelpful error messages.
> The only way to debug the problem is (a) to have complete stack traces and 
> (b) as much related information as possible.
> Zookeeper could do more here. Currently too much of the code loses stack 
> traces; sometimes auth errors aren't reported back to the client (the 
> connection is closed) +others
> Everyone who has tried to diagnose kerberos problems will appreciate 
> improvements here



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (ZOOKEEPER-1460) IPv6 literal address not supported for quorum members

[Raul Gutierrez Segales (JIRA)]

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

Raul Gutierrez Segales updated ZOOKEEPER-1460:
--
Fix Version/s: (was: 3.4.8)
   3.4.9

> IPv6 literal address not supported for quorum members
> -
>
> Key: ZOOKEEPER-1460
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1460
> Project: ZooKeeper
>  Issue Type: Bug
>  Components: quorum
>Affects Versions: 3.4.3
>Reporter: Chris Dolan
>Assignee: Joseph Walton
> Fix For: 3.4.9, 3.5.2, 3.6.0
>
> Attachments: 
> ZOOKEEPER-1460-accept-square-bracket-delimited-IPv6-literals.2.diff, 
> ZOOKEEPER-1460-accept-square-bracket-delimited-IPv6-literals.diff, 
> ZOOKEEPER-1460-for-3.5.0.patch, ZOOKEEPER-1460.003.patch
>
>
> Via code inspection, I see that the "server.nnn" configuration key does not 
> support literal IPv6 addresses because the property value is split on ":". In 
> v3.4.3, the problem is in QuorumPeerConfig:
> {noformat}
> String parts[] = value.split(":");
> InetSocketAddress addr = new InetSocketAddress(parts[0],
> Integer.parseInt(parts[1]));
> {noformat}
> In the current trunk 
> (http://svn.apache.org/viewvc/zookeeper/trunk/src/java/main/org/apache/zookeeper/server/quorum/QuorumPeer.java?view=markup)
>  this code has been refactored into QuorumPeer.QuorumServer, but the bug 
> remains:
> {noformat}
> String serverClientParts[] = addressStr.split(";");
> String serverParts[] = serverClientParts[0].split(":");
> addr = new InetSocketAddress(serverParts[0],
> Integer.parseInt(serverParts[1]));
> {noformat}
> This bug probably affects very few users because most will naturally use a 
> hostname rather than a literal IP address. But given that IPv6 addresses are 
> supported for clients via ZOOKEEPER-667 it seems that server support should 
> be fixed too.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (ZOOKEEPER-1460) IPv6 literal address not supported for quorum members

[Raul Gutierrez Segales (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-1460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15135489#comment-15135489
 ] 

Raul Gutierrez Segales commented on ZOOKEEPER-1460:
---

[~cnauroth]: lets target this in 3.4.9 - thanks!

> IPv6 literal address not supported for quorum members
> -
>
> Key: ZOOKEEPER-1460
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1460
> Project: ZooKeeper
>  Issue Type: Bug
>  Components: quorum
>Affects Versions: 3.4.3
>Reporter: Chris Dolan
>Assignee: Joseph Walton
> Fix For: 3.4.9, 3.5.2, 3.6.0
>
> Attachments: 
> ZOOKEEPER-1460-accept-square-bracket-delimited-IPv6-literals.2.diff, 
> ZOOKEEPER-1460-accept-square-bracket-delimited-IPv6-literals.diff, 
> ZOOKEEPER-1460-for-3.5.0.patch, ZOOKEEPER-1460.003.patch
>
>
> Via code inspection, I see that the "server.nnn" configuration key does not 
> support literal IPv6 addresses because the property value is split on ":". In 
> v3.4.3, the problem is in QuorumPeerConfig:
> {noformat}
> String parts[] = value.split(":");
> InetSocketAddress addr = new InetSocketAddress(parts[0],
> Integer.parseInt(parts[1]));
> {noformat}
> In the current trunk 
> (http://svn.apache.org/viewvc/zookeeper/trunk/src/java/main/org/apache/zookeeper/server/quorum/QuorumPeer.java?view=markup)
>  this code has been refactored into QuorumPeer.QuorumServer, but the bug 
> remains:
> {noformat}
> String serverClientParts[] = addressStr.split(";");
> String serverParts[] = serverClientParts[0].split(":");
> addr = new InetSocketAddress(serverParts[0],
> Integer.parseInt(serverParts[1]));
> {noformat}
> This bug probably affects very few users because most will naturally use a 
> hostname rather than a literal IP address. But given that IPv6 addresses are 
> supported for clients via ZOOKEEPER-667 it seems that server support should 
> be fixed too.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (ZOOKEEPER-2323) ZooKeeper client enters into infinite AuthFailedException cycle if its unable to recreate Kerberos ticket

[Raul Gutierrez Segales (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-2323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15135492#comment-15135492
 ] 

Raul Gutierrez Segales commented on ZOOKEEPER-2323:
---

[~fpj], [~Jobo], [~arshad.mohammad]: punting for 3.4.9. 

> ZooKeeper client enters into infinite AuthFailedException cycle if its unable 
> to recreate Kerberos ticket
> -
>
> Key: ZOOKEEPER-2323
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2323
> Project: ZooKeeper
>  Issue Type: Bug
>  Components: java client
>Affects Versions: 3.4.7, 3.5.1
>Reporter: Arshad Mohammad
>Assignee: Arshad Mohammad
> Fix For: 3.4.8, 3.5.2, 3.6.0
>
> Attachments: ZOOKEEPER-2323-01.patch
>
>
> ZooKeeper client enters into infinite AuthFailedException cycle. For every 
> operation its throws AuthFailedException
> Here is the create operation exception
> {code}
> org.apache.zookeeper.KeeperException$AuthFailedException: KeeperErrorCode = 
> AuthFailed for /continuousRunningZKClient
>   at org.apache.zookeeper.KeeperException.create(KeeperException.java:127)
>   at org.apache.zookeeper.KeeperException.create(KeeperException.java:51)
>   at org.apache.zookeeper.ZooKeeper.getData(ZooKeeper.java:1753)
> {code}
> This can be reproduced easily with the following steps:
> # Reduce the ZooKeeper client principal max life for example set 2 min.  use 
> command {color:blue} modprinc -maxlife 2min zkcli  {color} in kadmin. (This 
> is done to reduce the issue reproduce time)
> # Connect Client to ZooKeeper quorum,let it gets connected and some 
> operations are done successfully
> # Disconnect the Client's network, by pulling out the Ethernet cable or by 
> any way. Now the Client is in disconnected state, no operation is 
> expected,Client tries to reconnect to different-different servers in the 
> ZooKeeper quorum.
> # After two minutes Client tries to get new Keberos ticket and it fails.
> # Connect the Client to network. Client comes in connected state but 
> AuthFailedException for every operation.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (ZOOKEEPER-832) Invalid session id causes infinite loop during automatic reconnect

[Raul Gutierrez Segales (JIRA)]

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

Raul Gutierrez Segales updated ZOOKEEPER-832:
-
Fix Version/s: (was: 3.4.8)
   3.4.9

> Invalid session id causes infinite loop during automatic reconnect
> --
>
> Key: ZOOKEEPER-832
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-832
> Project: ZooKeeper
>  Issue Type: Bug
>  Components: server
>Affects Versions: 3.4.5, 3.5.0
> Environment: All
>Reporter: Ryan Holmes
>Assignee: Arshad Mohammad
>Priority: Critical
> Fix For: 3.4.9, 3.5.2, 3.6.0
>
> Attachments: ZOOKEEPER-832.patch, ZOOKEEPER-832.patch, 
> ZOOKEEPER-832.patch, ZOOKEEPER-832.patch, ZOOKEEPER-832.patch, 
> ZOOKEEPER-832.patch, ZOOKEEPER-832.patch, ZOOKEEPER-832.patch, 
> ZOOKEEPER-832.patch, ZOOKEEPER-832.patch
>
>
> Steps to reproduce:
> 1.) Connect to a standalone server using the Java client.
> 2.) Stop the server.
> 3.) Delete the contents of the data directory (i.e. the persisted session 
> data).
> 4.) Start the server.
> The client now automatically tries to reconnect but the server refuses the 
> connection because the session id is invalid. The client and server are now 
> in an infinite loop of attempted and rejected connections. While this 
> situation represents a catastrophic failure and the current behavior is not 
> incorrect, it appears that there is no way to detect this situation on the 
> client and therefore no way to recover.
> The suggested improvement is to send an event to the default watcher 
> indicating that the current state is "session invalid", similar to how the 
> "session expired" state is handled.
> Server log output (repeats indefinitely):
> 2010-08-05 11:48:08,283 - INFO  
> [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:2181:NIOServerCnxn$Factory@250] - 
> Accepted socket connection from /127.0.0.1:63292
> 2010-08-05 11:48:08,284 - INFO  
> [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:2181:NIOServerCnxn@751] - Refusing 
> session request for client /127.0.0.1:63292 as it has seen zxid 0x44 our last 
> zxid is 0x0 client must try another server
> 2010-08-05 11:48:08,284 - INFO  
> [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:2181:NIOServerCnxn@1434] - Closed 
> socket connection for client /127.0.0.1:63292 (no session established for 
> client)
> Client log output (repeats indefinitely):
> 11:47:17 org.apache.zookeeper.ClientCnxn startConnect INFO line 1000 - 
> Opening socket connection to server localhost/127.0.0.1:2181
> 11:47:17 org.apache.zookeeper.ClientCnxn run WARN line 1120 - Session 
> 0x12a3ae4e893000a for server null, unexpected error, closing socket 
> connection and attempting reconnect
> java.net.ConnectException: Connection refused
>   at sun.nio.ch.SocketChannelImpl.checkConnect(Native Method)
>   at 
> sun.nio.ch.SocketChannelImpl.finishConnect(SocketChannelImpl.java:574)
>   at org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:1078)
> 11:47:17 org.apache.zookeeper.ClientCnxn cleanup DEBUG line 1167 - Ignoring 
> exception during shutdown input
> java.nio.channels.ClosedChannelException
>   at 
> sun.nio.ch.SocketChannelImpl.shutdownInput(SocketChannelImpl.java:638)
>   at sun.nio.ch.SocketAdaptor.shutdownInput(SocketAdaptor.java:360)
>   at 
> org.apache.zookeeper.ClientCnxn$SendThread.cleanup(ClientCnxn.java:1164)
>   at org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:1129)
> 11:47:17 org.apache.zookeeper.ClientCnxn cleanup DEBUG line 1174 - Ignoring 
> exception during shutdown output
> java.nio.channels.ClosedChannelException
>   at 
> sun.nio.ch.SocketChannelImpl.shutdownOutput(SocketChannelImpl.java:649)
>   at sun.nio.ch.SocketAdaptor.shutdownOutput(SocketAdaptor.java:368)
>   at 
> org.apache.zookeeper.ClientCnxn$SendThread.cleanup(ClientCnxn.java:1171)
>   at org.apache.zookeeper.ClientCnxn$SendThread.run(ClientCnxn.java:1129)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (ZOOKEEPER-2044) CancelledKeyException in zookeeper 3.4.5

[Raul Gutierrez Segales (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-2044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15135491#comment-15135491
 ] 

Raul Gutierrez Segales commented on ZOOKEEPER-2044:
---

[~abranzyck] - thanks for the patch and sorry for the lack of review. Given we 
are running late with 3.4.8, lets get to this in 3.4.9. 

> CancelledKeyException in zookeeper 3.4.5
> 
>
> Key: ZOOKEEPER-2044
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2044
> Project: ZooKeeper
>  Issue Type: Bug
>  Components: server
>Affects Versions: 3.4.6
> Environment: Red Hat Enterprise Linux Server release 6.2
>Reporter: shamjith antholi
>Assignee: Germán Blanco
>Priority: Minor
> Fix For: 3.4.9
>
> Attachments: ZOOKEEPER-2044.patch
>
>
> I am getting cancelled key exception in zookeeper (version 3.4.5). Please see 
> the log below. When this error is thrown, the connected solr shard is going 
> down by giving the error "Failed to index metadata in 
> Solr,StackTrace=SolrError: HTTP status 503.Reason: 
> {"responseHeader":{"status":503,"QTime":204},"error":{"msg":"ClusterState 
> says we are the leader, but locally we don't think so","code":503"  and 
> ultimately the current activity is going down. Could you please give a 
> solution for this ?
> Zookeper log 
> --
> 2014-09-16 02:58:47,799 [myid:1] - INFO  
> [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:2181:ZooKeeperServer@832] - Client 
> attempting to renew session 0x24868e7ca980003 at /172.22.0.5:58587
> 2014-09-16 02:58:47,800 [myid:1] - INFO  
> [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:2181:Learner@107] - Revalidating 
> client: 0x24868e7ca980003
> 2014-09-16 02:58:47,802 [myid:1] - INFO  
> [QuorumPeer[myid=1]/0:0:0:0:0:0:0:0:2181:ZooKeeperServer@588] - Invalid 
> session 0x24868e7ca980003 for client /172.22.0.5:58587, probably expired
> 2014-09-16 02:58:47,803 [myid:1] - INFO  
> [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:2181:NIOServerCnxn@1001] - Closed 
> socket connection for client /172.22.0.5:58587 which had sessionid 
> 0x24868e7ca980003
> 2014-09-16 02:58:47,810 [myid:1] - ERROR 
> [CommitProcessor:1:NIOServerCnxn@180] - Unexpected Exception:
> java.nio.channels.CancelledKeyException
> at sun.nio.ch.SelectionKeyImpl.ensureValid(SelectionKeyImpl.java:55)
> at sun.nio.ch.SelectionKeyImpl.interestOps(SelectionKeyImpl.java:59)
> at 
> org.apache.zookeeper.server.NIOServerCnxn.sendBuffer(NIOServerCnxn.java:153)
> at 
> org.apache.zookeeper.server.NIOServerCnxn.sendResponse(NIOServerCnxn.java:1076)
> at 
> org.apache.zookeeper.server.NIOServerCnxn.process(NIOServerCnxn.java:1113)
> at org.apache.zookeeper.server.DataTree.setWatches(DataTree.java:1327)
> at 
> org.apache.zookeeper.server.ZKDatabase.setWatches(ZKDatabase.java:384)
> at 
> org.apache.zookeeper.server.FinalRequestProcessor.processRequest(FinalRequestProcessor.java:304)
> at 
> org.apache.zookeeper.server.quorum.CommitProcessor.run(CommitProcessor.java:74)
>  



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (ZOOKEEPER-2192) Port "Introduce new ZNode type: container" to 3.4.x

[Hadoop QA (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-2192?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15135520#comment-15135520
 ] 

Hadoop QA commented on ZOOKEEPER-2192:
--

-1 overall.  Here are the results of testing the latest attachment 
  http://issues.apache.org/jira/secure/attachment/12733880/ZOOKEEPER-2192.patch
  against trunk revision 1728577.

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

+1 tests included.  The patch appears to include 6 new or modified tests.

-1 patch.  The patch command could not apply the patch.

Console output: 
https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/3037//console

This message is automatically generated.

> Port "Introduce new ZNode type: container" to 3.4.x
> ---
>
> Key: ZOOKEEPER-2192
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2192
> Project: ZooKeeper
>  Issue Type: Sub-task
>  Components: c client, java client, server
>Affects Versions: 3.4.6
>Reporter: Jordan Zimmerman
>Assignee: Jordan Zimmerman
> Fix For: 3.4.9
>
> Attachments: ZOOKEEPER-2192.patch, ZOOKEEPER-2192.patch
>
>
> ZOOKEEPER-2163 applies to the trunk branch. This feature is too needed to 
> wait for 3.5.x. So, port the feature to the 3.4.x branch so it can be 
> released ahead of 3.5.x.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Failed: ZOOKEEPER-832 PreCommit Build #3036

[Apache Jenkins Server]

Jira: https://issues.apache.org/jira/browse/ZOOKEEPER-832
Build: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/3036/

###
## LAST 60 LINES OF THE CONSOLE 
###
[...truncated 381278 lines...]
 [exec] +1 @author.  The patch does not contain any @author tags.
 [exec] 
 [exec] +1 tests included.  The patch appears to include 2 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/3036//testReport/
 [exec] Findbugs warnings: 
https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/3036//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html
 [exec] Console output: 
https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/3036//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] 6e756c64ff33494cdb1ff2925428bd21d84d530f 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:1816:
 exec returned: 1

Total time: 17 minutes 58 seconds
Build step 'Execute shell' marked build as failure
Archiving artifacts
Setting 
LATEST1_7_HOME=/home/jenkins/jenkins-slave/tools/hudson.model.JDK/latest1.7
Recording test results
Setting 
LATEST1_7_HOME=/home/jenkins/jenkins-slave/tools/hudson.model.JDK/latest1.7
Setting 
LATEST1_7_HOME=/home/jenkins/jenkins-slave/tools/hudson.model.JDK/latest1.7
[description-setter] Description set: ZOOKEEPER-832
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any
Setting 
LATEST1_7_HOME=/home/jenkins/jenkins-slave/tools/hudson.model.JDK/latest1.7
Setting 
LATEST1_7_HOME=/home/jenkins/jenkins-slave/tools/hudson.model.JDK/latest1.7
Setting 
LATEST1_7_HOME=/home/jenkins/jenkins-slave/tools/hudson.model.JDK/latest1.7
Setting 
LATEST1_7_HOME=/home/jenkins/jenkins-slave/tools/hudson.model.JDK/latest1.7



###
## FAILED TESTS (if any) 
##
All tests passed

Failed: ZOOKEEPER-2192 PreCommit Build #3037

[Apache Jenkins Server]

Jira: https://issues.apache.org/jira/browse/ZOOKEEPER-2192
Build: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/3037/

###
## LAST 60 LINES OF THE CONSOLE 
###
[...truncated 377 lines...]
 [exec] Skipping patch.
 [exec] 1 out of 1 hunk ignored
 [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/12733880/ZOOKEEPER-2192.patch
 [exec]   against trunk revision 1728577.
 [exec] 
 [exec] +1 @author.  The patch does not contain any @author tags.
 [exec] 
 [exec] +1 tests included.  The patch appears to include 6 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/3037//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] 378a250b9abc13405d4af9bd5cb160d231c01a6c 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:1816:
 exec returned: 1

Total time: 42 seconds
Build step 'Execute shell' marked build as failure
Archiving artifacts
Setting 
LATEST1_7_HOME=/home/jenkins/jenkins-slave/tools/hudson.model.JDK/latest1.7
Recording test results
Setting 
LATEST1_7_HOME=/home/jenkins/jenkins-slave/tools/hudson.model.JDK/latest1.7
ERROR: Publisher 'Publish JUnit test result report' failed: No test report 
files were found. Configuration error?
Setting 
LATEST1_7_HOME=/home/jenkins/jenkins-slave/tools/hudson.model.JDK/latest1.7
[description-setter] Description set: ZOOKEEPER-2192
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any
Setting 
LATEST1_7_HOME=/home/jenkins/jenkins-slave/tools/hudson.model.JDK/latest1.7
Setting 
LATEST1_7_HOME=/home/jenkins/jenkins-slave/tools/hudson.model.JDK/latest1.7
Setting 
LATEST1_7_HOME=/home/jenkins/jenkins-slave/tools/hudson.model.JDK/latest1.7
Setting 
LATEST1_7_HOME=/home/jenkins/jenkins-slave/tools/hudson.model.JDK/latest1.7



###
## FAILED TESTS (if any) 
##
No tests ran.

[jira] [Updated] (ZOOKEEPER-2344) Provide more diagnostics/stack traces on SASL Auth failure

[Raul Gutierrez Segales (JIRA)]

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

Raul Gutierrez Segales updated ZOOKEEPER-2344:
--
Fix Version/s: (was: 3.4.8)
   3.4.9

> Provide more diagnostics/stack traces on SASL Auth failure
> --
>
> Key: ZOOKEEPER-2344
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2344
> Project: ZooKeeper
>  Issue Type: Improvement
>  Components: java client, server
>Affects Versions: 3.4.7, 3.5.1
>Reporter: Steve Loughran
> Fix For: 3.4.9, 3.5.2, 3.6.0
>
>
> When Kerberos decides it doesn't want to work, the JRE libraries provide some 
> terse and unhelpful error messages.
> The only way to debug the problem is (a) to have complete stack traces and 
> (b) as much related information as possible.
> Zookeeper could do more here. Currently too much of the code loses stack 
> traces; sometimes auth errors aren't reported back to the client (the 
> connection is closed) +others
> Everyone who has tried to diagnose kerberos problems will appreciate 
> improvements here



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (ZOOKEEPER-2044) CancelledKeyException in zookeeper 3.4.5

[Raul Gutierrez Segales (JIRA)]

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

Raul Gutierrez Segales updated ZOOKEEPER-2044:
--
Fix Version/s: (was: 3.4.8)
   3.4.9

> CancelledKeyException in zookeeper 3.4.5
> 
>
> Key: ZOOKEEPER-2044
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2044
> Project: ZooKeeper
>  Issue Type: Bug
>  Components: server
>Affects Versions: 3.4.6
> Environment: Red Hat Enterprise Linux Server release 6.2
>Reporter: shamjith antholi
>Assignee: Germán Blanco
>Priority: Minor
> Fix For: 3.4.9
>
> Attachments: ZOOKEEPER-2044.patch
>
>
> I am getting cancelled key exception in zookeeper (version 3.4.5). Please see 
> the log below. When this error is thrown, the connected solr shard is going 
> down by giving the error "Failed to index metadata in 
> Solr,StackTrace=SolrError: HTTP status 503.Reason: 
> {"responseHeader":{"status":503,"QTime":204},"error":{"msg":"ClusterState 
> says we are the leader, but locally we don't think so","code":503"  and 
> ultimately the current activity is going down. Could you please give a 
> solution for this ?
> Zookeper log 
> --
> 2014-09-16 02:58:47,799 [myid:1] - INFO  
> [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:2181:ZooKeeperServer@832] - Client 
> attempting to renew session 0x24868e7ca980003 at /172.22.0.5:58587
> 2014-09-16 02:58:47,800 [myid:1] - INFO  
> [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:2181:Learner@107] - Revalidating 
> client: 0x24868e7ca980003
> 2014-09-16 02:58:47,802 [myid:1] - INFO  
> [QuorumPeer[myid=1]/0:0:0:0:0:0:0:0:2181:ZooKeeperServer@588] - Invalid 
> session 0x24868e7ca980003 for client /172.22.0.5:58587, probably expired
> 2014-09-16 02:58:47,803 [myid:1] - INFO  
> [NIOServerCxn.Factory:0.0.0.0/0.0.0.0:2181:NIOServerCnxn@1001] - Closed 
> socket connection for client /172.22.0.5:58587 which had sessionid 
> 0x24868e7ca980003
> 2014-09-16 02:58:47,810 [myid:1] - ERROR 
> [CommitProcessor:1:NIOServerCnxn@180] - Unexpected Exception:
> java.nio.channels.CancelledKeyException
> at sun.nio.ch.SelectionKeyImpl.ensureValid(SelectionKeyImpl.java:55)
> at sun.nio.ch.SelectionKeyImpl.interestOps(SelectionKeyImpl.java:59)
> at 
> org.apache.zookeeper.server.NIOServerCnxn.sendBuffer(NIOServerCnxn.java:153)
> at 
> org.apache.zookeeper.server.NIOServerCnxn.sendResponse(NIOServerCnxn.java:1076)
> at 
> org.apache.zookeeper.server.NIOServerCnxn.process(NIOServerCnxn.java:1113)
> at org.apache.zookeeper.server.DataTree.setWatches(DataTree.java:1327)
> at 
> org.apache.zookeeper.server.ZKDatabase.setWatches(ZKDatabase.java:384)
> at 
> org.apache.zookeeper.server.FinalRequestProcessor.processRequest(FinalRequestProcessor.java:304)
> at 
> org.apache.zookeeper.server.quorum.CommitProcessor.run(CommitProcessor.java:74)
>  



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (ZOOKEEPER-2192) Port "Introduce new ZNode type: container" to 3.4.x

[Raul Gutierrez Segales (JIRA)]

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

Raul Gutierrez Segales updated ZOOKEEPER-2192:
--
Fix Version/s: (was: 3.4.8)
   3.4.9

> Port "Introduce new ZNode type: container" to 3.4.x
> ---
>
> Key: ZOOKEEPER-2192
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2192
> Project: ZooKeeper
>  Issue Type: Sub-task
>  Components: c client, java client, server
>Affects Versions: 3.4.6
>Reporter: Jordan Zimmerman
>Assignee: Jordan Zimmerman
> Fix For: 3.4.9
>
> Attachments: ZOOKEEPER-2192.patch, ZOOKEEPER-2192.patch
>
>
> ZOOKEEPER-2163 applies to the trunk branch. This feature is too needed to 
> wait for 3.5.x. So, port the feature to the 3.4.x branch so it can be 
> released ahead of 3.5.x.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (ZOOKEEPER-1884) zkCli silently ignores commands with missing parameters

[Raul Gutierrez Segales (JIRA)]

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

Raul Gutierrez Segales updated ZOOKEEPER-1884:
--
Fix Version/s: (was: 3.4.8)
   3.4.9

> 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.9
>
> 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] [Updated] (ZOOKEEPER-2184) Zookeeper Client should re-resolve hosts when connection attempts fail

[Raul Gutierrez Segales (JIRA)]

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

Raul Gutierrez Segales updated ZOOKEEPER-2184:
--
Fix Version/s: (was: 3.4.8)
   3.4.9

> Zookeeper Client should re-resolve hosts when connection attempts fail
> --
>
> Key: ZOOKEEPER-2184
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2184
> Project: ZooKeeper
>  Issue Type: Bug
>  Components: java client
>Affects Versions: 3.4.6, 3.5.0
> Environment: Ubuntu 14.04 host, Docker containers for Zookeeper & 
> Kafka
>Reporter: Robert P. Thille
>Assignee: Robert P. Thille
>  Labels: easyfix, patch
> Fix For: 3.4.9, 3.5.2
>
> Attachments: ZOOKEEPER-2184.patch
>
>
> Testing in a Docker environment with a single Kafka instance using a single 
> Zookeeper instance. Restarting the Zookeeper container will cause it to 
> receive a new IP address. Kafka will never be able to reconnect to Zookeeper 
> and will hang indefinitely. Updating DNS or /etc/hosts with the new IP 
> address will not help the client to reconnect as the 
> zookeeper/client/StaticHostProvider resolves the connection string hosts at 
> creation time and never re-resolves.
> A solution would be for the client to notice that connection attempts fail 
> and attempt to re-resolve the hostnames in the connectString.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (ZOOKEEPER-2192) Port "Introduce new ZNode type: container" to 3.4.x

[Raul Gutierrez Segales (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-2192?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15135495#comment-15135495
 ] 

Raul Gutierrez Segales commented on ZOOKEEPER-2192:
---

Given the issue we had with 3.4.7, I am now leaning towards not back-porting 
this into 3.4 and directing our efforts towards making 3.5 ready for wide 
consumption. 

> Port "Introduce new ZNode type: container" to 3.4.x
> ---
>
> Key: ZOOKEEPER-2192
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2192
> Project: ZooKeeper
>  Issue Type: Sub-task
>  Components: c client, java client, server
>Affects Versions: 3.4.6
>Reporter: Jordan Zimmerman
>Assignee: Jordan Zimmerman
> Fix For: 3.4.9
>
> Attachments: ZOOKEEPER-2192.patch, ZOOKEEPER-2192.patch
>
>
> ZOOKEEPER-2163 applies to the trunk branch. This feature is too needed to 
> wait for 3.5.x. So, port the feature to the 3.4.x branch so it can be 
> released ahead of 3.5.x.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (ZOOKEEPER-2243) Supported platforms is completely out of date

[Raul Gutierrez Segales (JIRA)]

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

Raul Gutierrez Segales updated ZOOKEEPER-2243:
--
Fix Version/s: (was: 3.4.8)
   3.4.9

> Supported platforms is completely out of date
> -
>
> Key: ZOOKEEPER-2243
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2243
> Project: ZooKeeper
>  Issue Type: Bug
>Reporter: Ivan Kelly
>Assignee: Chris Nauroth
> Fix For: 3.4.9, 3.5.2, 3.6.0
>
> Attachments: ZOOKEEPER-2243-branch-3.4.001.patch, 
> ZOOKEEPER-2243.001.patch
>
>
> http://zookeeper.apache.org/doc/r3.4.6/zookeeperAdmin.html#sc_supportedPlatforms
> It refers to Solaris as Sun Solaris so it's at least 5 years out of date.
> We should "support" the platforms that we are running zookeeper on regularly, 
> so I suggest paring it down to linux and windows (mac os doesn't really count 
> because people don't run it on servers anymore). Everything else should be 
> "may work, not supported, but will fix obvious bugs".



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (ZOOKEEPER-2323) ZooKeeper client enters into infinite AuthFailedException cycle if its unable to recreate Kerberos ticket

[Raul Gutierrez Segales (JIRA)]

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

Raul Gutierrez Segales updated ZOOKEEPER-2323:
--
Fix Version/s: (was: 3.4.8)
   3.4.9

> ZooKeeper client enters into infinite AuthFailedException cycle if its unable 
> to recreate Kerberos ticket
> -
>
> Key: ZOOKEEPER-2323
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2323
> Project: ZooKeeper
>  Issue Type: Bug
>  Components: java client
>Affects Versions: 3.4.7, 3.5.1
>Reporter: Arshad Mohammad
>Assignee: Arshad Mohammad
> Fix For: 3.4.9, 3.5.2, 3.6.0
>
> Attachments: ZOOKEEPER-2323-01.patch
>
>
> ZooKeeper client enters into infinite AuthFailedException cycle. For every 
> operation its throws AuthFailedException
> Here is the create operation exception
> {code}
> org.apache.zookeeper.KeeperException$AuthFailedException: KeeperErrorCode = 
> AuthFailed for /continuousRunningZKClient
>   at org.apache.zookeeper.KeeperException.create(KeeperException.java:127)
>   at org.apache.zookeeper.KeeperException.create(KeeperException.java:51)
>   at org.apache.zookeeper.ZooKeeper.getData(ZooKeeper.java:1753)
> {code}
> This can be reproduced easily with the following steps:
> # Reduce the ZooKeeper client principal max life for example set 2 min.  use 
> command {color:blue} modprinc -maxlife 2min zkcli  {color} in kadmin. (This 
> is done to reduce the issue reproduce time)
> # Connect Client to ZooKeeper quorum,let it gets connected and some 
> operations are done successfully
> # Disconnect the Client's network, by pulling out the Ethernet cable or by 
> any way. Now the Client is in disconnected state, no operation is 
> expected,Client tries to reconnect to different-different servers in the 
> ZooKeeper quorum.
> # After two minutes Client tries to get new Keberos ticket and it fails.
> # Connect the Client to network. Client comes in connected state but 
> AuthFailedException for every operation.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (ZOOKEEPER-2154) NPE in KeeperException

[Raul Gutierrez Segales (JIRA)]

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

Raul Gutierrez Segales updated ZOOKEEPER-2154:
--
Fix Version/s: (was: 3.4.8)
   3.4.9

> 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.6
>Reporter: Surendra Singh Lilhore
>Assignee: Surendra Singh Lilhore
> Fix For: 3.4.9, 3.5.2, 3.6.0
>
> 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-2243) Supported platforms is completely out of date

[Hadoop QA (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-2243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15135527#comment-15135527
 ] 

Hadoop QA commented on ZOOKEEPER-2243:
--

-1 overall.  Here are the results of testing the latest attachment 
  
http://issues.apache.org/jira/secure/attachment/12773117/ZOOKEEPER-2243-branch-3.4.001.patch
  against trunk revision 1728577.

+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/3040//console

This message is automatically generated.

> Supported platforms is completely out of date
> -
>
> Key: ZOOKEEPER-2243
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2243
> Project: ZooKeeper
>  Issue Type: Bug
>Reporter: Ivan Kelly
>Assignee: Chris Nauroth
> Fix For: 3.4.9, 3.5.2, 3.6.0
>
> Attachments: ZOOKEEPER-2243-branch-3.4.001.patch, 
> ZOOKEEPER-2243.001.patch
>
>
> http://zookeeper.apache.org/doc/r3.4.6/zookeeperAdmin.html#sc_supportedPlatforms
> It refers to Solaris as Sun Solaris so it's at least 5 years out of date.
> We should "support" the platforms that we are running zookeeper on regularly, 
> so I suggest paring it down to linux and windows (mac os doesn't really count 
> because people don't run it on servers anymore). Everything else should be 
> "may work, not supported, but will fix obvious bugs".



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (ZOOKEEPER-1884) zkCli silently ignores commands with missing parameters

[Hadoop QA (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-1884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15135525#comment-15135525
 ] 

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 1728577.

+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/3039//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.9
>
> 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 #3039

[Apache Jenkins Server]

Jira: https://issues.apache.org/jira/browse/ZOOKEEPER-1884
Build: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/3039/

###
## LAST 60 LINES OF THE CONSOLE 
###
[...truncated 96 lines...]
 [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 1728577.
 [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/3039//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] d66f5100079d38438ba34277911e34bec755e546 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:1816:
 exec returned: 1

Total time: 56 seconds
Build step 'Execute shell' marked build as failure
Archiving artifacts
Setting 
LATEST1_7_HOME=/home/jenkins/jenkins-slave/tools/hudson.model.JDK/latest1.7
Recording test results
Setting 
LATEST1_7_HOME=/home/jenkins/jenkins-slave/tools/hudson.model.JDK/latest1.7
ERROR: Publisher 'Publish JUnit test result report' failed: No test report 
files were found. Configuration error?
Setting 
LATEST1_7_HOME=/home/jenkins/jenkins-slave/tools/hudson.model.JDK/latest1.7
[description-setter] Description set: ZOOKEEPER-1884
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any
Setting 
LATEST1_7_HOME=/home/jenkins/jenkins-slave/tools/hudson.model.JDK/latest1.7
Setting 
LATEST1_7_HOME=/home/jenkins/jenkins-slave/tools/hudson.model.JDK/latest1.7
Setting 
LATEST1_7_HOME=/home/jenkins/jenkins-slave/tools/hudson.model.JDK/latest1.7
Setting 
LATEST1_7_HOME=/home/jenkins/jenkins-slave/tools/hudson.model.JDK/latest1.7



###
## FAILED TESTS (if any) 
##
No tests ran.

Failed: ZOOKEEPER-2243 PreCommit Build #3040

[Apache Jenkins Server]

Jira: https://issues.apache.org/jira/browse/ZOOKEEPER-2243
Build: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/3040/

###
## LAST 60 LINES OF THE CONSOLE 
###
[...truncated 94 lines...]
 [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/12773117/ZOOKEEPER-2243-branch-3.4.001.patch
 [exec]   against trunk revision 1728577.
 [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/3040//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] f0ae03be6b8fd6efccac87a5a80536ac5d46198c 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:1816:
 exec returned: 1

Total time: 54 seconds
Build step 'Execute shell' marked build as failure
Archiving artifacts
Setting 
LATEST1_7_HOME=/home/jenkins/jenkins-slave/tools/hudson.model.JDK/latest1.7
Recording test results
Setting 
LATEST1_7_HOME=/home/jenkins/jenkins-slave/tools/hudson.model.JDK/latest1.7
ERROR: Publisher 'Publish JUnit test result report' failed: No test report 
files were found. Configuration error?
Setting 
LATEST1_7_HOME=/home/jenkins/jenkins-slave/tools/hudson.model.JDK/latest1.7
[description-setter] Description set: ZOOKEEPER-2243
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any
Setting 
LATEST1_7_HOME=/home/jenkins/jenkins-slave/tools/hudson.model.JDK/latest1.7
Setting 
LATEST1_7_HOME=/home/jenkins/jenkins-slave/tools/hudson.model.JDK/latest1.7
Setting 
LATEST1_7_HOME=/home/jenkins/jenkins-slave/tools/hudson.model.JDK/latest1.7
Setting 
LATEST1_7_HOME=/home/jenkins/jenkins-slave/tools/hudson.model.JDK/latest1.7



###
## FAILED TESTS (if any) 
##
No tests ran.

[jira] [Commented] (ZOOKEEPER-2154) NPE in KeeperException

[Hadoop QA (JIRA)]

[ 
https://issues.apache.org/jira/browse/ZOOKEEPER-2154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15135529#comment-15135529
 ] 

Hadoop QA commented on ZOOKEEPER-2154:
--

-1 overall.  Here are the results of testing the latest attachment 
  http://issues.apache.org/jira/secure/attachment/12708466/ZOOKEEPER-2154.patch
  against trunk revision 1728577.

+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 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/3038//testReport/
Findbugs warnings: 
https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/3038//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html
Console output: 
https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/3038//console

This message is automatically generated.

> 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.6
>Reporter: Surendra Singh Lilhore
>Assignee: Surendra Singh Lilhore
> Fix For: 3.4.9, 3.5.2, 3.6.0
>
> Attachments: ZOOKEEPER-2154.patch
>
>
> KeeperException should handle exception is code is null...



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Failed: ZOOKEEPER-2154 PreCommit Build #3038

[Apache Jenkins Server]

Jira: https://issues.apache.org/jira/browse/ZOOKEEPER-2154
Build: https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/3038/

###
## LAST 60 LINES OF THE CONSOLE 
###
[...truncated 384006 lines...]
 [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 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/3038//testReport/
 [exec] Findbugs warnings: 
https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/3038//artifact/trunk/build/test/findbugs/newPatchFindbugsWarnings.html
 [exec] Console output: 
https://builds.apache.org/job/PreCommit-ZOOKEEPER-Build/3038//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] 61f77645d0ffe870d12cbbcdae9187eaeba2df48 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:1816:
 exec returned: 1

Total time: 18 minutes 4 seconds
Build step 'Execute shell' marked build as failure
Archiving artifacts
Setting 
LATEST1_7_HOME=/home/jenkins/jenkins-slave/tools/hudson.model.JDK/latest1.7
Recording test results
Setting 
LATEST1_7_HOME=/home/jenkins/jenkins-slave/tools/hudson.model.JDK/latest1.7
Setting 
LATEST1_7_HOME=/home/jenkins/jenkins-slave/tools/hudson.model.JDK/latest1.7
[description-setter] Description set: ZOOKEEPER-2154
Email was triggered for: Failure - Any
Sending email for trigger: Failure - Any
Setting 
LATEST1_7_HOME=/home/jenkins/jenkins-slave/tools/hudson.model.JDK/latest1.7
Setting 
LATEST1_7_HOME=/home/jenkins/jenkins-slave/tools/hudson.model.JDK/latest1.7
Setting 
LATEST1_7_HOME=/home/jenkins/jenkins-slave/tools/hudson.model.JDK/latest1.7
Setting 
LATEST1_7_HOME=/home/jenkins/jenkins-slave/tools/hudson.model.JDK/latest1.7



###
## FAILED TESTS (if any) 
##
All tests passed

Re: `winstdint.h` and MSVC

[Alex Clemmer]

Hey folks. Not sure if someone responded and I just didn't see it
because I'm not on the dev@ list, or if there just isn't that much
interest in these questions. Can someone please at least confirm that
I've not screwed up sending this message somehow?

On Thu, Jan 28, 2016 at 3:24 PM, Alex Clemmer
 wrote:
> I should note also that I have looked closely at the issue tracker
> (e.g., https://issues.apache.org/jira/browse/ZOOKEEPER-1953) and
> various related changesets (e.g.,
> http://svn.apache.org/viewvc?view=revision=1148116) but being
> young and raised mostly on git I could not find a discussion of why
> this file is the way that it is. So it could well be that I am simply
> missing simple guidance like "make sure not to include `stdint.h` in
> any project consuming the ZK C client library."
>
> On Thu, Jan 28, 2016 at 3:18 PM, Alex Clemmer
>  wrote:
>> Hey folks.
>>
>> We (the Apache Mesos project) are building against the ZK C client on
>> Windows, with VS 2015 (and MSVC v.1900). When we attempt a vanilla
>> build, including both `zookeeper.h` and `stdint.h` causes the compiler
>> to complain that we're re-typedef'ing a few types (such as
>> `int_fast8_t` with different underlying types) in the file,
>> `winstdint.h`.
>>
>> I have scoured the Internet to see if I'm missing a -D flag somewhere,
>> but it does not appear that this is the case.
>>
>> The comments in this file state that it's meant to provide a
>> C9X-compliant version of `stdint.h` for Windows, but for later
>> versions of MSVC some of the definitions seem to be redundant or
>> different. (For example, on VS 2013 `int_fast16_t` is redefined with a
>> different underlying type.)
>>
>> My question for you all is: am I missing something obvious, or should
>> I submit a bug and a patch to resolve this issue for you?
>>
>>
>> --
>> Alex
>>
>> Theory is the first term in the Taylor series of practice. -- Thomas M
>> Cover (1992)
>
>
>
> --
> Alex
>
> Theory is the first term in the Taylor series of practice. -- Thomas M
> Cover (1992)



-- 
Alex

Theory is the first term in the Taylor series of practice. -- Thomas M
Cover (1992)

Re: `winstdint.h` and MSVC

[Alex Clemmer]

Ah, ok, I've subscribed to dev@ to avoid this mistake in the future.
Thanks a lot for the heads up!

Let me answer your questions directly, and then step back and address
the broader scope of maintaining robust support for modern platforms.

We currently have no specific reason to believe that the Mesos code
base is suffering bugs from the `stdint.h` warnings, but it is
nonetheless worrying to us, because it means that the platform is
probably not well-trafficked for our target. That said, in the
immediate term, I'm willing to start with the fairly modest goal of
figuring out the "best way" to get the C client to integrate with
realistic codebases, which I personally think includes getting the C
client to compile in the presence of the totally-reasonable-to-include
`stdint.h` header.

For next steps, I think the best thing to do is to open a ticket to
just get this to compile in the presence of `stdint.h`, and then
incrementally build out more robust, modern support from there. From
there I'm happy to do the leg work to fix these issues.

Stepping back: given that we expect this code to run on tens of
thousands of more-modern Windows nodes (via Mesos), I think we
probably all agree that it would be a good outcome to have a high
level of operational predictability in the client. I am guessing we
are also in agreement that this probably involves cleaning up the
warnings. In the longer term I think this also means exposing more
levers to people consuming these libraries -- for example, right now
the `.vcxproj` files only build DLLs, but for a lot of reasons we want
to allow people to choose, if not actually actually make it
static-by-default (for example, DLLs have totally separate heaps in
win32, and this presents some interesting issues at scale) .

I'm happy to collate my suggestions into a list in the future. Let me
know what would be useful for that conversation. I'm happy to make
this an extended discussion and co-evolve the codebase as we find
issues deploying it at scale.

On Fri, Feb 5, 2016 at 3:58 PM, Chris Nauroth  wrote:
> Hi Alex,
>
> I replied to this on Monday, 2/1.  I'm copy-pasting the same reply below,
> and this time I've put your email address on the To: line explicitly.
>
>
>
> I looked into this, and I can repro.  I think this is a bug, and I don't
> think any of the recent Windows fixes addresses it.  Although "make sure
> you don't include stdint.h" is a viable workaround, it's not best for us
> to put artificial constraints on our users.
>
> Modern versions of Visual Studio do ship a stdint.h header, which negates
> the need for the winstdint.h compatibility shim.  I think a stdint.h is
> available in at least Visual Studio 2010 and later.  One potential fix
> would be to remove winstdint.h, transition completely to use of stdint.h,
> and declare that our supported build tool chain is Visual Studio 2010 and
> later.  I'm reluctant to do that on the 3.4 maintenance line though on
> grounds of backwards-compatibility.  Another approach could be conditional
> compilation to include either stdint.h or winstdint.h based on choice.  I
> see a flag named HAVE_STDINT_H mentioned in winconfig.h, so it seems like
> someone was thinking of this.  However, the flag is unused from what I can
> tell, so it wouldn't actually help for a project to define it before
> compiling.  We'd need to make code changes to support it.
>
> On a side note, there are numerous other compilation warnings on Windows,
> unrelated to stdint.h.
>
> Alex, do you think you are experiencing a bug from the stdint.h warnings?
> I'm trying to decide if we should file a single JIRA for a mass cleanup of
> warnings, or if the stdint.h warnings you reported are somehow more
> critical than the rest and need tracking in their own separate issue.
>
>
> --Chris Nauroth
>
>
>
>
> On 2/5/16, 3:53 PM, "Alex Clemmer"  wrote:
>
>>Hey folks. Not sure if someone responded and I just didn't see it
>>because I'm not on the dev@ list, or if there just isn't that much
>>interest in these questions. Can someone please at least confirm that
>>I've not screwed up sending this message somehow?
>>
>>On Thu, Jan 28, 2016 at 3:24 PM, Alex Clemmer
>> wrote:
>>> I should note also that I have looked closely at the issue tracker
>>> (e.g., https://issues.apache.org/jira/browse/ZOOKEEPER-1953) and
>>> various related changesets (e.g.,
>>> http://svn.apache.org/viewvc?view=revision=1148116) but being
>>> young and raised mostly on git I could not find a discussion of why
>>> this file is the way that it is. So it could well be that I am simply
>>> missing simple guidance like "make sure not to include `stdint.h` in
>>> any project consuming the ZK C client library."
>>>
>>> On Thu, Jan 28, 2016 at 3:18 PM, Alex Clemmer
>>>  wrote:
 Hey folks.

 We (the Apache Mesos project) are building against the ZK C client on
 Windows, 

Re: `winstdint.h` and MSVC

[Chris Nauroth]

Hi Alex,

I replied to this on Monday, 2/1.  I'm copy-pasting the same reply below,
and this time I've put your email address on the To: line explicitly.



I looked into this, and I can repro.  I think this is a bug, and I don't
think any of the recent Windows fixes addresses it.  Although "make sure
you don't include stdint.h" is a viable workaround, it's not best for us
to put artificial constraints on our users.

Modern versions of Visual Studio do ship a stdint.h header, which negates
the need for the winstdint.h compatibility shim.  I think a stdint.h is
available in at least Visual Studio 2010 and later.  One potential fix
would be to remove winstdint.h, transition completely to use of stdint.h,
and declare that our supported build tool chain is Visual Studio 2010 and
later.  I'm reluctant to do that on the 3.4 maintenance line though on
grounds of backwards-compatibility.  Another approach could be conditional
compilation to include either stdint.h or winstdint.h based on choice.  I
see a flag named HAVE_STDINT_H mentioned in winconfig.h, so it seems like
someone was thinking of this.  However, the flag is unused from what I can
tell, so it wouldn't actually help for a project to define it before
compiling.  We'd need to make code changes to support it.

On a side note, there are numerous other compilation warnings on Windows,
unrelated to stdint.h.

Alex, do you think you are experiencing a bug from the stdint.h warnings?
I'm trying to decide if we should file a single JIRA for a mass cleanup of
warnings, or if the stdint.h warnings you reported are somehow more
critical than the rest and need tracking in their own separate issue.


--Chris Nauroth




On 2/5/16, 3:53 PM, "Alex Clemmer"  wrote:

>Hey folks. Not sure if someone responded and I just didn't see it
>because I'm not on the dev@ list, or if there just isn't that much
>interest in these questions. Can someone please at least confirm that
>I've not screwed up sending this message somehow?
>
>On Thu, Jan 28, 2016 at 3:24 PM, Alex Clemmer
> wrote:
>> I should note also that I have looked closely at the issue tracker
>> (e.g., https://issues.apache.org/jira/browse/ZOOKEEPER-1953) and
>> various related changesets (e.g.,
>> http://svn.apache.org/viewvc?view=revision=1148116) but being
>> young and raised mostly on git I could not find a discussion of why
>> this file is the way that it is. So it could well be that I am simply
>> missing simple guidance like "make sure not to include `stdint.h` in
>> any project consuming the ZK C client library."
>>
>> On Thu, Jan 28, 2016 at 3:18 PM, Alex Clemmer
>>  wrote:
>>> Hey folks.
>>>
>>> We (the Apache Mesos project) are building against the ZK C client on
>>> Windows, with VS 2015 (and MSVC v.1900). When we attempt a vanilla
>>> build, including both `zookeeper.h` and `stdint.h` causes the compiler
>>> to complain that we're re-typedef'ing a few types (such as
>>> `int_fast8_t` with different underlying types) in the file,
>>> `winstdint.h`.
>>>
>>> I have scoured the Internet to see if I'm missing a -D flag somewhere,
>>> but it does not appear that this is the case.
>>>
>>> The comments in this file state that it's meant to provide a
>>> C9X-compliant version of `stdint.h` for Windows, but for later
>>> versions of MSVC some of the definitions seem to be redundant or
>>> different. (For example, on VS 2013 `int_fast16_t` is redefined with a
>>> different underlying type.)
>>>
>>> My question for you all is: am I missing something obvious, or should
>>> I submit a bug and a patch to resolve this issue for you?
>>>
>>>
>>> --
>>> Alex
>>>
>>> Theory is the first term in the Taylor series of practice. -- Thomas M
>>> Cover (1992)
>>
>>
>>
>> --
>> Alex
>>
>> Theory is the first term in the Taylor series of practice. -- Thomas M
>> Cover (1992)
>
>
>
>-- 
>Alex
>
>Theory is the first term in the Taylor series of practice. -- Thomas M
>Cover (1992)
>

Re: `winstdint.h` and MSVC

[Chris Nauroth]

That all sounds great!

At this point, I suggest filing one ZooKeeper JIRA issue to track the
short-term stdint.h fix.  Please also feel free to file any number of
additional issues for the longer-term requests, such as the request to
support static linking.

--Chris Nauroth




On 2/5/16, 4:40 PM, "Alex Clemmer"  wrote:

>Ah, ok, I've subscribed to dev@ to avoid this mistake in the future.
>Thanks a lot for the heads up!
>
>Let me answer your questions directly, and then step back and address
>the broader scope of maintaining robust support for modern platforms.
>
>We currently have no specific reason to believe that the Mesos code
>base is suffering bugs from the `stdint.h` warnings, but it is
>nonetheless worrying to us, because it means that the platform is
>probably not well-trafficked for our target. That said, in the
>immediate term, I'm willing to start with the fairly modest goal of
>figuring out the "best way" to get the C client to integrate with
>realistic codebases, which I personally think includes getting the C
>client to compile in the presence of the totally-reasonable-to-include
>`stdint.h` header.
>
>For next steps, I think the best thing to do is to open a ticket to
>just get this to compile in the presence of `stdint.h`, and then
>incrementally build out more robust, modern support from there. From
>there I'm happy to do the leg work to fix these issues.
>
>Stepping back: given that we expect this code to run on tens of
>thousands of more-modern Windows nodes (via Mesos), I think we
>probably all agree that it would be a good outcome to have a high
>level of operational predictability in the client. I am guessing we
>are also in agreement that this probably involves cleaning up the
>warnings. In the longer term I think this also means exposing more
>levers to people consuming these libraries -- for example, right now
>the `.vcxproj` files only build DLLs, but for a lot of reasons we want
>to allow people to choose, if not actually actually make it
>static-by-default (for example, DLLs have totally separate heaps in
>win32, and this presents some interesting issues at scale) .
>
>I'm happy to collate my suggestions into a list in the future. Let me
>know what would be useful for that conversation. I'm happy to make
>this an extended discussion and co-evolve the codebase as we find
>issues deploying it at scale.
>
>On Fri, Feb 5, 2016 at 3:58 PM, Chris Nauroth 
>wrote:
>> Hi Alex,
>>
>> I replied to this on Monday, 2/1.  I'm copy-pasting the same reply
>>below,
>> and this time I've put your email address on the To: line explicitly.
>>
>>
>>
>> I looked into this, and I can repro.  I think this is a bug, and I don't
>> think any of the recent Windows fixes addresses it.  Although "make sure
>> you don't include stdint.h" is a viable workaround, it's not best for us
>> to put artificial constraints on our users.
>>
>> Modern versions of Visual Studio do ship a stdint.h header, which
>>negates
>> the need for the winstdint.h compatibility shim.  I think a stdint.h is
>> available in at least Visual Studio 2010 and later.  One potential fix
>> would be to remove winstdint.h, transition completely to use of
>>stdint.h,
>> and declare that our supported build tool chain is Visual Studio 2010
>>and
>> later.  I'm reluctant to do that on the 3.4 maintenance line though on
>> grounds of backwards-compatibility.  Another approach could be
>>conditional
>> compilation to include either stdint.h or winstdint.h based on choice.
>>I
>> see a flag named HAVE_STDINT_H mentioned in winconfig.h, so it seems
>>like
>> someone was thinking of this.  However, the flag is unused from what I
>>can
>> tell, so it wouldn't actually help for a project to define it before
>> compiling.  We'd need to make code changes to support it.
>>
>> On a side note, there are numerous other compilation warnings on
>>Windows,
>> unrelated to stdint.h.
>>
>> Alex, do you think you are experiencing a bug from the stdint.h
>>warnings?
>> I'm trying to decide if we should file a single JIRA for a mass cleanup
>>of
>> warnings, or if the stdint.h warnings you reported are somehow more
>> critical than the rest and need tracking in their own separate issue.
>>
>>
>> --Chris Nauroth
>>
>>
>>
>>
>> On 2/5/16, 3:53 PM, "Alex Clemmer"  wrote:
>>
>>>Hey folks. Not sure if someone responded and I just didn't see it
>>>because I'm not on the dev@ list, or if there just isn't that much
>>>interest in these questions. Can someone please at least confirm that
>>>I've not screwed up sending this message somehow?
>>>
>>>On Thu, Jan 28, 2016 at 3:24 PM, Alex Clemmer
>>> wrote:
 I should note also that I have looked closely at the issue tracker
 (e.g., https://issues.apache.org/jira/browse/ZOOKEEPER-1953) and
 various related changesets (e.g.,
 http://svn.apache.org/viewvc?view=revision=1148116) but being
 young 

[VOTE] Apache ZooKeeper release 3.4.8 candidate 0

[Raúl Gutiérrez Segalés]

This is a bugfix release candidate for 3.4.8. It fixes 9 issues, most
notably a deadlock when shutting down ZooKeeper.

The full release notes is available at:

https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310801=12326517

*** Please download, test and vote by February 20th 2016, 23:59 UTC+0. ***

Source files:
http://people.apache.org/~rgs/zookeeper-3-4-8-rc0/

Maven staging repo:
https://repository.apache.org/content/groups/staging/org/apache/zookeeper/zookeeper/3.4.8/

The tag to be voted upon:
https://svn.apache.org/repos/asf/zookeeper/tags/release-3.4.8-rc0

ZooKeeper's KEYS file containing PGP keys we use to sign the release:
http://www.apache.org/dist/zookeeper/KEYS

Should we release this candidate?

Note that the approval is by lazy majority according to the bylaws and only
PMC votes are binding.


-rgs