[
https://issues.apache.org/jira/browse/PHOENIX-3360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15852818#comment-15852818
]
William Yang commented on PHOENIX-3360:
---------------------------------------
PHOENIX-3360-v2.patch attached, [~jamestaylor]. In this version, only the
mutations originated from the HTableInterface created by
CoprocessorHTableFactory will have high priority. I've read PHOENIX-3271,
unfortunately, this patch will break the assumption that all cross RS calls are
made with higher priority, as we didn't change the coprocessor env's
configuration, we just created a new hbase connection with specific
configurations.
The optimal way to make things right is to use separate handler queues for read
and write. Sharing the same handler queue with index requests might not be the
best idea, because if there are many UPSERT SELECTs, index updates might not
have enough threads to be executed. And this will slow down the mutations of
data table.
On the other hand, separate RW handler queues are not always configured and we
cannot force users to config this. In this case, we still have to make UPSERT
SELECT's batch mutations have higher priority. Later I'll attach a V3 patch to
fix this.
WDYT, [~jamestaylor]
> Secondary index configuration is wrong
> --------------------------------------
>
> Key: PHOENIX-3360
> URL: https://issues.apache.org/jira/browse/PHOENIX-3360
> 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 https://phoenix.apache.org/secondary_indexing.html 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
(v6.3.15#6346)
