[
https://issues.apache.org/jira/browse/PHOENIX-3994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16084733#comment-16084733
]
James Taylor commented on PHOENIX-3994:
---------------------------------------
I like [~vincentpoon]'s idea: how about setting the config on the targetHTable
similar to the way Vincent did for his related JIRA? We know the scope of the
htable is limited to just this invocation and also limited to UPSERT SELECT.
{code}
if (upsertSelectTable != null) {
isUpsert = true;
projectedTable = deserializeTable(upsertSelectTable);
targetHTable = new HTable(env.getConfiguration(),
projectedTable.getPhysicalName().getBytes());
+ Configuration tableConf = targetHTable.getConfiguration();
// TODO: set configs necessary for RPC to be higher priority
{code}
Also, can use the necessary config (maybe already are?) such that we get the
optimization of local writes bypassing the RPC stack?
> Index RPC priority still depends on the controller factory property in
> hbase-site.xml
> -------------------------------------------------------------------------------------
>
> Key: PHOENIX-3994
> URL: https://issues.apache.org/jira/browse/PHOENIX-3994
> Project: Phoenix
> Issue Type: Bug
> Affects Versions: 4.11.0
> Reporter: Sergey Soldatov
> Assignee: Samarth Jain
> Priority: Critical
> Fix For: 4.12.0, 4.11.1
>
> Attachments: PHOENIX-3994_addendum.patch, PHOENIX-3994.patch,
> PHOENIX-3994_v2.patch, PHOENIX-3994_v3.patch
>
>
> During PHOENIX-3360 we tried to remove dependency on
> hbase.rpc.controllerfactory.class property in hbase-site.xml since it cause
> problems on the client side (if client is using server side configuration,
> all client request may go using index priority). Committed solution is using
> setting the controller factory programmatically for coprocessor environment
> in Indexer class, but it comes that this solution doesn't work because the
> environment configuration is not used for the coprocessor connection
> creation. We need to provide a better solution since this issue may cause
> accidental locks and failures that hard to identify and avoid.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
