[ 
https://issues.apache.org/jira/browse/PHOENIX-4130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16332971#comment-16332971
 ] 

Vincent Poon commented on PHOENIX-4130:
---------------------------------------

[~jamestaylor] Attached v2 patch, please review.  Implemented the following 
based on your suggestions:
 * add PENDING_DISABLE state.  If it's been in this state past a certain 
threshold, the client no longer uses it, and the rebuilder will change the 
state to DISABLE
 * add failure handling to UngroupedAggregateRegionObserver.commit() , for 
mutations that don't go through the client's MutationState
 * pass back the QueryServices.INDEX_FAILURE_DISABLE_INDEX config setting via 
the exception that is thrown back to the client, so that it only needs to be 
set on the server side
 * use IndexUtil.updateIndexState instead of "alter index" statement

I don't think there's a way to detect # of retries on a successful mutation, so 
currently if we transition to PENDING_DISABLE on the first attempt, then the 
subsequent attempt succeeds, we rely on the rebuilder to transition back to 
ACTIVE (and duplicating mutations in the process).

Would be good if you can double check that the PENDING_DISABLE checks are in 
the right places - I looked through the usages of PENDING_ACTIVE and modified 
the ones that looked appropriate.

> 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.v2.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)

Reply via email to