phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <>
Subject [jira] [Commented] (PHOENIX-3189) HBase/ZooKeeper connection leaks when providing principal/keytab in JDBC url
Date Fri, 26 Aug 2016 20:37:21 GMT


ASF GitHub Bot commented on PHOENIX-3189:

Github user joshelser commented on the issue:
    > Would an alternative be to not rely on the User.equals method, but instead modify
ConnectionInfo.equals to do some other kind of equality check on User?
    I think I initially had this idea too (wondering why User doesn't implement a "normal"
value-based equals/hashCode implementation). Devaraj didn't remember exactly why, but he recalled
that there was a reason that UGI (and thus User also) did this. I could try to dig into the
Hadoop archives to see if I can understand why this was done.
    Mostly, I think this approach keeps us in line with what HDFS and HBase does now which
has some value.

> HBase/ZooKeeper connection leaks when providing principal/keytab in JDBC url
> ----------------------------------------------------------------------------
>                 Key: PHOENIX-3189
>                 URL:
>             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

View raw message