[
https://issues.apache.org/jira/browse/HBASE-19301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16259598#comment-16259598
]
stack commented on HBASE-19301:
-------------------------------
bq. Only the connection created within RS will use this way.
Yeah. Calls setupClusterConnection which does this:
return ConnectionUtils.createShortCircuitConnection(conf, null,
userProvider.getCurrent(),
serverName, rpcServices, rpcServices);
.. which creates ShortCircuitingClusterConnection instance which does nothing
but switch on what the destination server is; if local, then short-circuit the
stub invocation (but the pb marshall/unmarshalling still happens).
It is almost as though we should always create a
ShortCircuitingClusterConnection. Would be good in unit test context! Perhaps
we should offer it as an option on ConnectionFactory.
bq. Are there 2 short circuit stuff? I dont know.
There might be. There is the one described above that skips RPC but still does
marshall/unmarshall of request and params over protobuf.
Then there is what the pre-hbase2 CoprocessorHConnection could supposedly do.
Here is from the javadoc:
{code}
* Connection to an HTable from within a Coprocessor. We can do some nice
tricks since we know we
* are on a regionserver, for instance skipping the full
serialization/deserialization of objects
* when talking to the server.
{code}
Only, I see no evidence it did the above. It just ended up calling
ConnectionFactory#createConnection like anyone else; it didn't even do the
skirting of RPC, nevermind the saving on pb marshalling/unmarshalling.
The CPHConnection came in with
commit 6bc48464ca10d403474bc6d8ff93c8814caa8c8d
Author: jyates <jyates@unknown>
Date: Wed Sep 18 18:18:58 2013 +0000
HBASE-9534: Short-Circuit Coprocessor HTable access when on the same server
It did this initially...
+ public static HConnection getConnectionForEnvironment(CoprocessorEnvironment
env)
+ throws IOException {
+ HConnection connection =
HConnectionManager.createConnection(env.getConfiguration());
+ // this bit is a little hacky - just trying to get it going for the moment
+ if (env instanceof RegionCoprocessorEnvironment) {
+ RegionCoprocessorEnvironment e = (RegionCoprocessorEnvironment) env;
+ RegionServerServices services = e.getRegionServerServices();
+ if (services instanceof HRegionServer) {
+ return new CoprocessorHConnection(connection, (HRegionServer)
services);
+ }
+ }
+ return connection;
+ }
... so, it did what our short-circuit does, skip RPC.
I don't think it ever did any more.
So, when looking at CPHConneciton as part of the CP API redo, I just removed
it; it was trying to do something we already did and looking at it now, was
actually failing to do that even.
Ideally we'd do what was promised in the comment on CPHConneciton and avoid PB
if possible. We'd do it for any short-circuit connection not just a CP
short-circuit.
So, sorry for the long-winded comment. To answer your question, yeah, if a CP
wants to make its own Connection with its own Config (a rare necessity, no?
Phoenix doesn't even need it -- they might need it?), they should be able to
get a Connection that can short-circuit. They should be able to get it from the
CpEnv. I was going to suggest that CpEnv should have a getConnectionFactory
and this server-side ConnectionFactory would have an option to get a
short-circuiting Conneciton .... but then I looked at your patch. Your patch is
much cleaner... simple.
+1 on the patch. On commit, add a comment to the getConnection ... no
Configuration. I think you have to be clear on the diff between the two
methods. A comment in the getConnection (no COnfiguration) would say, if you
want to create your own Connection with your own Configuration and NOT use the
RegionServer Connection (though its cache of locations will be warm, it
short-circuits, and its life-cycle is not the concern of the CP), see
#getConnection(Configuration)... that kinda thing.
Thanks [~anoop.hbase]
> 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.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)
