[ 
https://issues.apache.org/jira/browse/PHOENIX-3189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15453938#comment-15453938
 ] 

Hudson commented on PHOENIX-3189:
---------------------------------

FAILURE: Integrated in Jenkins build Phoenix-master #1377 (See 
[https://builds.apache.org/job/Phoenix-master/1377/])
PHOENIX-3189 Perform Kerberos login before ConnectionInfo is constructed 
(elserj: rev 2dc6be4e9ffb205aaa5b0f6a1f2746eed8d23426)
* (add) 
phoenix-core/src/test/java/org/apache/phoenix/jdbc/SecureUserConnectionsTest.java
* (edit) phoenix-core/src/main/java/org/apache/phoenix/jdbc/PhoenixDriver.java
* (edit) phoenix-core/pom.xml
* (edit) 
phoenix-core/src/main/java/org/apache/phoenix/query/ConnectionQueryServicesImpl.java
* (edit) phoenix-core/src/test/resources/log4j.properties
* (edit) 
phoenix-core/src/main/java/org/apache/phoenix/jdbc/PhoenixEmbeddedDriver.java
* (edit) 
phoenix-core/src/main/java/org/apache/phoenix/util/InstanceResolver.java
* (edit) pom.xml


> HBase/ZooKeeper connection leaks when providing principal/keytab in JDBC url
> ----------------------------------------------------------------------------
>
>                 Key: PHOENIX-3189
>                 URL: https://issues.apache.org/jira/browse/PHOENIX-3189
>             Project: Phoenix
>          Issue Type: Bug
>    Affects Versions: 4.8.0
>            Reporter: Josh Elser
>            Assignee: Josh Elser
>            Priority: Blocker
>             Fix For: 4.9.0, 4.8.1
>
>
> We've been doing some more testing after PHOENIX-3126 and, with the help of 
> [~arpitgupta] and [~harsha_ch], we've found an issue in a test between Storm 
> and Phoenix.
> Storm was configured to create a JDBC Bolt, specifying the principal and 
> keytab in the JDBC URL, relying on PhoenixDriver to do the Kerberos login for 
> them. After PHOENIX-3126, a ZK server blacklisted the host running the bolt, 
> and we observed that there were over 140 active ZK threads in the JVM.
> This results in a subtle change where every time the client tries to get a 
> new Connection, we end up getting a new UGI instance (because the 
> {{ConnectionQueryServicesImpl#openConnection()}} always does a new login).
> If users are correctly caching Connections, there isn't an issue (best as I 
> can presently tell). However, if users rely on the getting the same 
> connection every time (the pre-PHOENIX-3126), they will saturate their local 
> JVM with connections and crash.



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

Reply via email to