[
https://issues.apache.org/jira/browse/PHOENIX-4130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16144906#comment-16144906
]
Andrew Purtell commented on PHOENIX-4130:
-----------------------------------------
This may make things better for the average case but if we will have to wait
under lock for the failed index timestamp update aren't we still liable to
block all handlers on waits if under an error condition we pile up failures?
Instead of setting a timestamp upon failure can we track timestamps with an
inverse semantic when the index write succeeds? This may be a lot harder
because the absence of a timestamp update is the indication somehow that the
index is not up to date, but the likelihood of piling up during failure is nil
because upon failure somewhere we need no writes to succeed.
> 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
>
> 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
(v6.4.14#64029)
