[
https://issues.apache.org/jira/browse/HBASE-19301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16279186#comment-16279186
]
stack commented on HBASE-19301:
-------------------------------
[~zghaobac], [~anoop.hbase], and I fell into an off-list conversation on this
issue. Let me surface at least some of our conclusions here (others to surface
elsewhere regards which user a CP should execute calls as...).
Was agreed that we need to remove getConnection. CPs should not have access to
the RS Connection especially given it grants superuser access to the Cluster
and closing it will wreak havoc on hosting RS (Guanghao and Anoop worked this
out). Will try to address this immediate problem here with the reopen of this
issue. CPs must do createConnection.
Other items such as which User we create the Connection with will be addressed
in follow-ons; they are generic CP issues not particular here.
I spent some time trying to remove getConnection in favor of a createConnection
that defaulted short-circuiting. On removing #getConnection, I am not thinking
we should just leave it. The idea was to replace getConnection with
createConnection; i.e. a Coprocessor would make its own Connection per instance
(if 1000 regions on a Server and each with 10 Coprocessors that want to connect
to other regions, then we'd have 10k Connection out of the RegionServer each
doing a hit against hbase:meta to populate its own cache of locations... ). But
the real problem is that the createConnection is only available in Coprocessor
sub-environments like MasterCoprocessorEnvironment and
RegionCoprocessorEnvironment. #createConnection is NOT available in
CoprocessorEnvironment. When #start is called on a Coprocessor, we do not pass
the specialization. We pass the base CoprocessorEnvironment. So a CP that wants
to create a Connection for the life of the CP, will want to do it on #start.
But it has to cast CE to MCE or RCE to get at the createConnection. Ugly.
Complicated. They need to close it too.
Looking at a few current uses of getConnection, it is to do some minor stuff.
The CP can just do getConnection whenever it needs it because the Connection is
already up and its cache populated....
Yeah, its superuser.
How about leaving getConnection with warnings and then adding createConnection
for those who need something more hardcore or specialized?
In hbase3, we do better cleanup?
(I tried passing MasterCoprocessor#start a specialized
MasterCoprocessorEnvironment. This won't work though because we sometimes have
a CP implement a few specializations: e.g. it can be loaded as
MasterCoprocessor and as a RegionCoprocessor).
> Provide way for CPs to create short circuited connection with custom
> configurations
> -----------------------------------------------------------------------------------
>
> Key: HBASE-19301
> URL: https://issues.apache.org/jira/browse/HBASE-19301
> Project: HBase
> Issue Type: Sub-task
> Components: Coprocessors
> Reporter: Anoop Sam John
> Assignee: Anoop Sam John
> Fix For: 2.0.0-beta-1
>
> Attachments: HBASE-19301-addendum.patch, HBASE-19301.patch,
> HBASE-19301_V2.patch, HBASE-19301_V2.patch
>
>
> Over in HBASE-18359 we have discussions for this.
> Right now HBase provide getConnection() in RegionCPEnv, MasterCPEnv etc. But
> this returns a pre created connection (per server). This uses the configs at
> hbase-site.xml at that server.
> Phoenix needs creating connection in CP with some custom configs. Having this
> custom changes in hbase-site.xml is harmful as that will affect all
> connections been created at that server.
> This issue is for providing an overloaded getConnection(Configuration) API
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
