[
https://issues.apache.org/jira/browse/PHOENIX-4130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16341384#comment-16341384
]
ASF GitHub Bot commented on PHOENIX-4130:
-----------------------------------------
Github user JamesRTaylor commented on a diff in the pull request:
https://github.com/apache/phoenix/pull/290#discussion_r164171049
--- Diff:
phoenix-core/src/main/java/org/apache/phoenix/optimize/QueryOptimizer.java ---
@@ -312,6 +317,16 @@ private static QueryPlan addPlan(PhoenixStatement
statement, SelectStatement sel
return null;
}
+ // returns true if we can still use the index
+ // retuns false if we've been in PENDING_DISABLE too long - index
should be considered disabled
+ private static boolean isUnderPendingDisableThreshold(PhoenixStatement
statement, PTable indexTable) {
+ return EnvironmentEdgeManager
+ .currentTimeMillis() -
indexTable.getIndexDisableTimestamp() <= statement
--- End diff --
This runs on the client-side, but the INDEX_DISABLED_TIMESTAMP was set on
the server-side, so we can't necessarily reliably compare them. Instead, we
should store the client timestamp when we first received the exception and
compare the client-side current time with that. Perhaps a good place to store
this pendingDisableInitialTimestamp would be on the index TableRef which would
not be shared across multiple threads.
Also, minor nit: whenever possible (if on client-side), use
.getConnection().getQueryServices().getProps() instead of going through
Configuration. We created this ReadOnlyProps which is essentially a copy of
Configuration but as an read-only, immutable map because we were seeing
contention on the locking done by Configuration (which is not necessary because
it's used in an immutable way). You can also add an
indexPendingDisableThreshold as a member variable to QueryOptimizer.
> 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, PHOENIX-4130.v3.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)
