phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Samarth Jain (JIRA)" <>
Subject [jira] [Updated] (PHOENIX-3994) Index RPC priority still depends on the controller factory property in hbase-site.xml
Date Thu, 06 Jul 2017 19:16:00 GMT


Samarth Jain updated PHOENIX-3994:
    Attachment: PHOENIX-3994.patch

Patch with a test that repro's the fact that the IndexRpcScheduler is not used for handling
index updates when the ServerRpcControllerFactory isn't configured in the region server's

I also have a proposed solution which I am not 100% sure is the right thing to do. Basically,
the change is to directly use the HConnection created by HConnectionManager and not the CoprocessorHConnection.
The reasoning being the we handle local index updates by going through the HRegion#batchMutate
api and not through HTable. So we won't be risking running into a deadlock or other performance

I also changed the default of running UPSERT SELECT on server side as I think it needs us
to fix PHOENIX-3995 first.

[~jamestaylor], [~enis], [~rajeshbabu] - please review. 

> 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
>            Priority: Critical
>         Attachments: PHOENIX-3994.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