[
https://issues.apache.org/jira/browse/PHOENIX-1676?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14340926#comment-14340926
]
Jesse Yates commented on PHOENIX-1676:
--------------------------------------
bq. Could this be why PhoenixIndexRpcScheduler.dispatch is not being called for
the index updates?
So the stack you posted is just from the client side. As I mentioned (and you
copied above): "getClient method just goes straight into the rpc scheduler of
the HRegionServer", which looking again at the code should instead be "rpc
services of the HRegionServer" (my bad!). This is what is used by the
server-side indexing mechanism, so the indexing queues are not used when *index
regions are on the same server*.
What I think you need to test that it being processed by writing a test that
runs *2 regionservers* and that ensures that the primary and index tables are
on different servers and then running the update and ensuring that it uses the
dispatch (maybe by having an update mechanism - latch? static variable? write
to another table? - in a custom subclass that you look for during the test).
bq. I also tried creating a simple htable, but
IndexQosRpcController.setPriority is not getting called for this table.
That is not quite what you are doing in that test. What I was getting at
offline was that you should just use the standard HBase api's, rather than
dealing with *any phoenix components* to ensure that nothing is coming into
play. So just use a MiniHBaseCluster (via a HBaseTestingUtility), set the
expected properties in the configs, create the tables using an HBaseAdmin (from
the Util#getHBaseAdmin) and then write to the table. You should see the updates
going through the expected paths (or there is something wrong).
You have already found a small bug which, will need to be fixed as part of this
patch, specifically, what you said offline:
bq. In IndexQosCompat.rpcControllerExists(), should the first check be if
(!checked) ?
But that is a small aside to the larger test you should be writing.
> Set priority of Index Updates correctly
> ----------------------------------------
>
> Key: PHOENIX-1676
> URL: https://issues.apache.org/jira/browse/PHOENIX-1676
> Project: Phoenix
> Issue Type: Bug
> Reporter: Thomas D'Silva
> Assignee: Thomas D'Silva
>
> I spoke to Jesse offline about this.
> The priority of index updates isn't being set correctly because of the use of
> CoprocessorHConnection (which all coprocessors use if they create an HTable
> via the CPEnvironment).
> Specifically the flow happens like this: the CoprocessorHTableFactory
> attempts to set the connection qos factory, but it is ignored because the
> CoprocessorHConnection is used (instead of a standard HConnection) and the
> #getClient method just goes straight into the rpc scheduler of the
> HRegionServer, if its on the same server. This allows the region to be
> directly accessed, but without actually going over the loopback or
> serializing any information.
> However, this means it ignores the configured rpccontroller factory and the
> override setting of the rpc priority. We probably shouldn't be runtime
> changing the configuration - instead we should probably be using some other
> serialized information.
> The primary fix would seems to be that the regionserver needs to be
> configured with the IndexQosRpcControllerFactory and then use a static map
> (or cache of the index metadata) to set the qos for the index servers.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
