phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vincent Poon (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (PHOENIX-4130) Avoid server retries for mutable indexes
Date Wed, 31 Jan 2018 02:12:02 GMT

    [ 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)

Mime
View raw message