hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gary Helmling (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (HBASE-7482) Port HBASE-7442 HBase remote CopyTable not working when security enabled to trunk
Date Wed, 06 Mar 2013 22:56:14 GMT

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

Gary Helmling updated HBASE-7482:

    Attachment: HBASE-7482-v2.patch

Passing the cluster ID through Configuration was originally a hack to avoid more invasive
changes to ClientCache and the RPC engine layers that would have been required to directly
represent cluster ID.

Now that we've already undertaking the removal of ClientCache and refactoring of RPC engines
in 0.95/trunk, I think we're better off removing the Configuration pass-through completely.

Here's a modified patch that removes the mucking with Configuration and just passes through
cluster ID as an honest-to-goodness parameter.  I think this winds up being cleaner.

James, let me know your thoughts or if you can picture situations this might break.
> Port HBASE-7442 HBase remote CopyTable not working when security enabled to trunk
> ---------------------------------------------------------------------------------
>                 Key: HBASE-7482
>                 URL: https://issues.apache.org/jira/browse/HBASE-7482
>             Project: HBase
>          Issue Type: Bug
>            Reporter: Ted Yu
>            Assignee: James Kinley
>            Priority: Critical
>             Fix For: 0.95.0
>         Attachments: HBASE-7482-trunk.patch, HBASE-7482-v2.patch
> Excerpt about the choice of solution from :
> The first option was actually quite messy to implement. {{clusterId}} and {{conf}} are
fixed in *{{HBaseClient}}* when it's created and cached by *{{SecureRpcEngine}}*, so to implement
the fix here I would have had to pass the different cluster {{confs}} up through *{{HConnectionManager}}*
and *{{HBaseRPC}}* in order to override the clusterId in *{{SecureClient#SecureConnection}}*.
> I've gone with the second option of creating and caching different *{{SecureClients}}*
for the local and remote clusters in *{{SecureRpcEngine}}* - keyed off of the {{clusterId}}
instead of the default *{{SocketFactory}}*. I think this is a cleaner solution.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

View raw message