phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vincent Poon (JIRA)" <>
Subject [jira] [Commented] (PHOENIX-3994) Index RPC priority still depends on the controller factory property in hbase-site.xml
Date Wed, 12 Jul 2017 22:08:00 GMT


Vincent Poon commented on PHOENIX-3994:

[~samarthjain] I looked at the comment you linked to earlier - in RegionCoprocessorHost#getTableCoprocessorAttrsFromSchema
, it does look like they make a copy of the config.  So technically I think you're right that
the conf is limited in scope, but probably still safer to do a copy.  If you do it in the
HTableFactory you would only have to do it once, anyways, and all HTables would get it.
The clone in UngroupedAggregateRegionObserver looks like maybe it could be tweaked to happen
only once, as it looks like it's doing it every time now just to set that one property, which
is static.

> Index RPC priority still depends on the controller factory property in hbase-site.xml
> -------------------------------------------------------------------------------------
>                 Key: PHOENIX-3994
>                 URL:
>             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,
> 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

View raw message