[
https://issues.apache.org/jira/browse/PHOENIX-3891?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Josh Elser updated PHOENIX-3891:
--------------------------------
Attachment: PHOENIX-3891.001.patch
.001 Pretty simple change to make the parsing a bit more intelligent.
I lament that I couldn't get the test passing in all environments by providing
a custom krb5.conf. Something was a little busted -- makes the test case a bit
more contrived than I wanted (but still better than nothing).
> ConnectionQueryServices leak on auto-Kerberos-login without REALM in URL
> ------------------------------------------------------------------------
>
> Key: PHOENIX-3891
> URL: https://issues.apache.org/jira/browse/PHOENIX-3891
> Project: Phoenix
> Issue Type: Bug
> Reporter: Josh Elser
> Assignee: Josh Elser
> Priority: Critical
> Fix For: 4.11.0
>
> Attachments: PHOENIX-3891.001.patch
>
>
> PHOENIX-3189 fixed some logic in construction of a {{ConnectionInfo}} to,
> when requested by the user, perform the Kerberos login and then construct and
> cache the ConnectionInfo->ConnectionQueryServices pair.
> This approach only works when the principal that the user provides in the
> JDBC url is exactly what UGI returns as the short name. Logically equivalent
> principals will result in re-logging in each time and leaking
> ConnectionQueryService instances (and thus HConnection and ZooKeeper objects).
> For example, with Kerberos principals there is a default realm which is
> implied by krb5.conf when not explicitly provided. Thus: {{elserj}} and
> {{elserj@APACHE}} would be considered logically equivalent (when the default
> realm is "APACHE"). We should expand the {{isSameName}} check in
> ConnectionInfo to be a bit smarter.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
