phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Taylor (JIRA)" <>
Subject [jira] [Commented] (PHOENIX-4130) Avoid server retries for mutable indexes
Date Tue, 30 Jan 2018 03:14:00 GMT


James Taylor commented on PHOENIX-4130:

Looks good, with one minor nit. Just remove the extra check you added here to do nothing if
the old/new state are DISABLE and the INDEX_DISABLE_TIMESTAMP is the same. I remember a case
where we want this to go through so that the cell timestamp changes.
+                    // potential race condition between client and rebuilder
+                    // when transitioning from PENDING_DISABLE -> DISABLE.  Noop in that
+                    if (newState == PIndexState.DISABLE && Math.abs(curTimeStampVal)
== Math.abs(newDisableTimeStamp)) {
+                        builder.setReturnCode(MetaDataProtos.MutationCode.TABLE_ALREADY_EXISTS);
+                        builder.setMutationTime(EnvironmentEdgeManager.currentTimeMillis());
+              ;
+                        return;
+                    }

> Avoid server retries for mutable indexes
> ----------------------------------------
>                 Key: PHOENIX-4130
>                 URL:
>             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, PHOENIX-4130.v3.master.patch,
PHOENIX-4130.v4.master.patch, PHOENIX-4130.v5.master.patch, PHOENIX-4130.v6.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

View raw message