[
https://issues.apache.org/jira/browse/PHOENIX-3360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15554065#comment-15554065
]
James Taylor commented on PHOENIX-3360:
---------------------------------------
bq. The problem with relying on HBASE-15816 would be that ALL requests should
be explicitly tagged with the correct priority.
I thought the RS->RS index updates were the ones we want to flag? If that's the
case, there's only one place in the code where we do that. Attempting to
statically define tables as high versus low priority can break down. For
example, with PHOENIX-6, we'll need to maintain indexes on immutable tables on
the server side for these new type of statements. We can't know this
statically. We can always add the right abstraction to make the code evolution
smooth. Too much magic usually backfires in my experience.
Definitely agree that the lack of context passed into the RPCController is it's
biggest drawback. Even if that changed, though, having special configuration
requirements will always be brittle.
> 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
> Priority: Critical
>
> 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.4#6332)
