[jira] [Comment Edited] (HBASE-9117) Remove HTablePool and all HConnection pooling related APIs

["Nick Dimiduk (JIRA)" <ji...@apache.org>]

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

Nick Dimiduk edited comment on HBASE-9117 at 3/4/14 6:09 PM:
-------------------------------------------------------------

Here's what I have in mind in terms of breakdown of work.

{noformat}
 1. warn on connection cache hit (configurable, off by default. 0.98)
 2. deprecate all public HTable constructors (0.98)
 3. deprecate ConnectionManager#{delete,get}Connection (0.98)
 4. replace internal ConnectionManager#{delete,get}Connection use with #close, #createConnection (0.98, 0.99)
 5. replace internal HTable constructor use with HConnection#getTable (0.98, 0.99)
 6. delete all public HTable constructors (0.99)
 7. delete ConnectionManager#{delete,get}Connection (0.99)
{noformat}

There's some other tasks mixed in there as well that will be required to replace internal usage patterns. Thinks like MetaReader#getRegionCount accepting an HConnection instance instead of a Configuration. Will tease those out as I go.

Does this plan make sense? I don't want to create a bunch of JIRA noise without reasonable consensus. I'll push a pile of patches to a github branch so you can see what things are looking like.

Formatting edited for legibility.


was (Author: ndimiduk):
Here's what I have in mind in terms of breakdown of work.

 # warn on connection cache hit (configurable, off by default. 0.98)
 # deprecate all public HTable constructors (0.98)
 # deprecate ConnectionManager#{delete,get}Connection (0.98)
 # replace internal ConnectionManager#{delete,get}Connection use with #close, #createConnection (0.98, 0.99)
 # replace internal HTable constructor use with HConnection#getTable (0.98, 0.99)
 # delete all public HTable constructors (0.99)
 # delete ConnectionManager#{delete,get}Connection (0.99)

There's some other tasks mixed in there as well that will be required to replace internal usage patterns. Thinks like MetaReader#getRegionCount accepting an HConnection instance instead of a Configuration. Will tease those out as I go.

Does this plan make sense? I don't want to create a bunch of JIRA noise without reasonable consensus. I'll push a pile of patches to a github branch so you can see what things are looking like.

> Remove HTablePool and all HConnection pooling related APIs
> ----------------------------------------------------------
>
>                 Key: HBASE-9117
>                 URL: https://issues.apache.org/jira/browse/HBASE-9117
>             Project: HBase
>          Issue Type: Bug
>            Reporter: Lars Hofhansl
>            Assignee: Nick Dimiduk
>            Priority: Critical
>             Fix For: 0.99.0
>
>         Attachments: HBASE-9117.00.patch, HBASE-9117.01.patch, HBASE-9117.02.patch, HBASE-9117.03.patch, HBASE-9117.04.patch, HBASE-9117.05.patch, HBASE-9117.06.patch
>
>
> The recommended way is now:
> # Create an HConnection: HConnectionManager.createConnection(...)
> # Create a light HTable: HConnection.getTable(...)
> # table.close()
> # connection.close()
> All other API and pooling will be removed.



--
This message was sent by Atlassian JIRA
(v6.2#6252)