[
https://issues.apache.org/jira/browse/PHOENIX-4130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16346140#comment-16346140
]
Vincent Poon commented on PHOENIX-4130:
---------------------------------------
[~jamestaylor] I'm running into the following problem with 1.2 and lower
branches. We don't have PHOENIX-3827 (write local index mutations along with
data atomically) in those branches, and so in theory there can be a local index
write failure. The problem is when we get the index write failure exception in
the IndexCommitter, all we have is the HTableInterfaceReference, which points
to the data table. Before, when we were disabling the index on the server
side, we could determine if the referenced table was the same as the local
region, and if it was, we could get the HTableDescriptor and then do a lookup
of the column families and determine if there are local indexes. We can then
determine the local index names from the HTableInterface and the mutations.
Now that we're disabling from the client, I'm thinking I'll have to do one of
the following:
* Modify the committer such that we extract all the local index names on the
server side when the failure happens using
PhoenixIndexFailurePolicy#getLocalIndexNames, then pass all that information
back to the client in the exception string
* On the client side, after retries are done, do a rpc call to get the table
descriptor to determine whether there are local indexes, and then extract the
local index names using something like
PhoenixIndexFailurePolicy#getLocalIndexNames
Neither approach seems great - any thoughts, or ideas on a simpler way to do
this?
> Avoid server retries for mutable indexes
> ----------------------------------------
>
> Key: PHOENIX-4130
> URL: https://issues.apache.org/jira/browse/PHOENIX-4130
> Project: Phoenix
> Issue Type: Improvement
> Reporter: Lars Hofhansl
> Assignee: Vincent Poon
> Priority: Major
> Fix For: 4.14.0
>
> Attachments: PHOENIX-4130.v1.master.patch,
> PHOENIX-4130.v10.master.patch, PHOENIX-4130.v2.master.patch,
> PHOENIX-4130.v3.master.patch, PHOENIX-4130.v4.master.patch,
> PHOENIX-4130.v5.master.patch, PHOENIX-4130.v6.master.patch,
> PHOENIX-4130.v7.master.patch, PHOENIX-4130.v8.master.patch,
> PHOENIX-4130.v9.master.patch
>
>
> Had some discussions with [~jamestaylor], [~samarthjain], and [~vincentpoon],
> during which I suggested that we can possibly eliminate retry loops happening
> at the server that cause the handler threads to be stuck potentially for
> quite a while (at least multiple seconds to ride over common scenarios like
> splits).
> Instead we can do the retries at the Phoenix client that.
> So:
> # The index updates are not retried on the server. (retries = 0)
> # A failed index update would set the failed index timestamp but leave the
> index enabled.
> # Now the handler thread is done, it throws an appropriate exception back to
> the client.
> # The Phoenix client can now retry. When those retries fail the index is
> disabled (if the policy dictates that) and throw the exception back to its
> caller.
> So no more waiting is needed on the server, handler threads are freed
> immediately.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
