[
https://issues.apache.org/jira/browse/HBASE-9117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13925335#comment-13925335
]
Nick Dimiduk commented on HBASE-9117:
-------------------------------------
bq. What is the above Nick Dimiduk? Because we are going to undo caching
connections?
Unless I'm mistaken, that's the meaning of "HConnection pooling related APIs".
With no way to have a "managed" connection, the user must explicitly create and
destroy their own. This warning will notify when this deprecated behavior is
invoked.
{quote}
Might be a bit radical for 0.98 since it is out but since internal, might be ok.
ditto.
{quote}
These are invasive yes. See WIP patches WIP.04, WIP.05, WIP.06 in the github
branch.
bq. Going by the rule book, there is not be enough deprecation time – given
0.98.0 has shipped.
Yes, that's true.
bq. I think HTablePool has to stay for 1.0 even though broke.
I wish very much to at least get rid of this for 1.0 (even if the connection
cache remains). It's difficult to use correctly and HConnection has been around
long enough that people are using it mostly, I think. Further, if we introduce
the new API as we've discussed with [~enis], 1.0 will ship with no fewer than 5
ways to acquire a handle on a cluster table (HTablePool#getTable,
HTableFactory#createHTableInterface, "managed" HTables via constructor,
HConnection#getTable, and whatever our new 1.0 API looks like). Surely we can
drop *something*. The pool and the factory are my preference.
bq. The Connection setup is heavy, right? To ZK, and then to RS. If a
Connection per, is there sharing?
As I understand it, yes, it is heavy weight. That why the patch is large, I
unwind placed were an implicitly cached connection is (hopefully) retrieved via
Configuration and instead explicitly hold an HConnection and thread it through
where a Configuration once went. That way, the connection is explicitly shared
instead of implicitly via the cache. Easier to reason about, simpler to trace.
bq. Can we get some of the work in at least? The first few items in your list?
I hope we can take it as far as removing use of the connection cache in our
internal implementation for 1.0 (through WIP.06). Leave it around for users if
we must, though by our rules, we won't be able to drop it until 2.0 at the
earliest.
> 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)
