phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William Yang (JIRA)" <>
Subject [jira] [Commented] (PHOENIX-3360) Secondary index configuration is wrong
Date Thu, 09 Feb 2017 02:23:41 GMT


William Yang commented on PHOENIX-3360:

bq. What's the problem facing by setting the RPC class at RS level instead of region level?

Considering the replication requests, when slave cluster is handling replication requests,
slave RSs will send RPC to other RSs in the same cluster. If we set an RS level RPC config,
then all replication requests will be handled by the index handlers in those RSs instead of
the normal handlers. 

Usually, a slave cluster is not just a slave, it may also be active for user requests. For
example, cluster A is master, B is the slave, and a table T1 is replicated from A to B. Clients'
daily access will be handled by A. Then, we may create some phoenix tables on B without replication
because the load of cluster B is relatively low. For users of these phoenix tables, they will
access cluster B directly. This is not an active-active mode, but cluster B is both slave
and 'master' here. Moreover, in an active-active mode, this is a problem that must be solved.

Using the slave cluster as a normal cluster might not be standard, but leaving the slave cluster
in a low load is also a waste. 

bq. With William Yang's patch the short-circuit write optimization will not work because the
connection created is not a coprocessor connection.

What is the 'short-circuit write optimization', by the way?

> Secondary index configuration is wrong
> --------------------------------------
>                 Key: PHOENIX-3360
>                 URL:
>             Project: Phoenix
>          Issue Type: Bug
>            Reporter: Enis Soztutar
>            Assignee: Rajeshbabu Chintaguntla
>            Priority: Critical
>             Fix For: 4.10.0
>         Attachments: PHOENIX-3360.patch, PHOENIX-3360-v2.PATCH
> IndexRpcScheduler allocates some handler threads and uses a higher priority for RPCs.
The corresponding IndexRpcController is not used by default as it is, but used through ServerRpcControllerFactory
that we configure from Ambari by default which sets the priority of the outgoing RPCs to either
metadata priority, or the index priority.
> However, after reading code of IndexRpcController / ServerRpcController it seems that
the IndexRPCController DOES NOT look at whether the outgoing RPC is for an Index table or
not. It just sets ALL rpc priorities to be the index priority. The intention seems to be the
case that ONLY on servers, we configure ServerRpcControllerFactory, and with clients we NEVER
configure ServerRpcControllerFactory, but instead use ClientRpcControllerFactory. We configure
ServerRpcControllerFactory from Ambari, which in affect makes it so that ALL rpcs from Phoenix
are only handled by the index handlers by default. It means all deadlock cases are still there.

> The documentation in is also wrong
in this sense. It does not talk about server side / client side. Plus this way of configuring
different values is not how HBase configuration is deployed. We cannot have the configuration
show the ServerRpcControllerFactory even only for server nodes, because the clients running
on those nodes will also see the wrong values. 

This message was sent by Atlassian JIRA

View raw message