[
https://issues.apache.org/jira/browse/PHOENIX-2221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15116726#comment-15116726
]
James Taylor commented on PHOENIX-2221:
---------------------------------------
[~ayingshu] - IMHO, it's ok to simulate the index write failure through another
means. See TxWriteFailureIT.FailingRegionObserver for an example of adding a
coprocessor for that purpose. I seem to recall that we have a long standing
JIRA about problems with disabling an HBase table (which would be good to fix
too).
It's *not* correct that the commit succeeds, though. When the data table is
written to, the index table is written to as well. It's essential that we throw
an exception at commit time if the index table cannot be written to. If that's
not the case, that's a serious bug in and of itself and definitely needs to be
fixed. After that, your patch may work as expected.
It's also not correct that two rows be returned for the data table query. The
whole point of holding the upper timestamp of the data table at the point where
the index write failure occurred is to prevent the rows written to the data
table from being returned to the client. The whole point of this feature is to
improve the consistency of mutable secondary indexes under these kind of
failure scenarios. It's a bit frustrating explaining to you how the feature
you're supposed to be building should work.
> Option to make data regions not writable when index regions are not available
> -----------------------------------------------------------------------------
>
> Key: PHOENIX-2221
> URL: https://issues.apache.org/jira/browse/PHOENIX-2221
> Project: Phoenix
> Issue Type: Improvement
> Reporter: Devaraj Das
> Assignee: Alicia Ying Shu
> Fix For: 4.8.0
>
> Attachments: DelegateIndexFailurePolicy.java, PHOENIX-2221-v1.patch,
> PHOENIX-2221-v2.patch, PHOENIX-2221-v3.patch, PHOENIX-2221-v4.patch,
> PHOENIX-2221-v5.patch, PHOENIX-2221-v6.patch, PHOENIX-2221.patch,
> PHOENIX-2221.wip, PHOENIX-2221_v7.patch
>
>
> In one usecase, it was deemed better to not accept writes when the index
> regions are unavailable for any reason (as opposed to disabling the index and
> the queries doing bigger data-table scans).
> The idea is that the index regions are kept consistent with the data regions,
> and when a query runs against the index regions, one can be reasonably sure
> that the query ran with the most recent data in the data regions. When the
> index regions are unavailable, the writes to the data table are rejected.
> Read queries off of the index regions would have deterministic performance
> (and on the other hand if the index is disabled, then the read queries would
> have to go to the data regions until the indexes are rebuilt, and the queries
> would suffer).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
