[
https://issues.apache.org/jira/browse/PHOENIX-3994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16081709#comment-16081709
]
Samarth Jain commented on PHOENIX-3994:
---------------------------------------
bq. Just to confirm, your patch causes our existing setting of the
CUSTOM_CONTROLLER_CONF_KEY here in Indexer to take effect as we expect?
Yes. See the changes in BaseTest. Earlier we were setting the
ServerRpcControllerFactory by default in our tests. After I removed that,
PhoenixServerRpcIT was failing. With my change, it works again as expected
(i.e. the index handler pool is used for handling index updates)
bq. Can you file an HBase JIRA if you haven't already and reference that JIRA
in a comment on that method?
Done. HBASE-18359
bq. Will this be done in a separate JIRA?
Yes it will be fixed as part of PHOENIX-3995. I will file another JIRA to
disable distributed upsert select in the meantime when a table has global
mutable index on it since users can run into deadlocks without PHOENIX-3995
fixed.
> 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
> Priority: Critical
> Attachments: PHOENIX-3994.patch, PHOENIX-3994_v2.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)
