[
https://issues.apache.org/jira/browse/PHOENIX-3953?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16157293#comment-16157293
]
Hadoop QA commented on PHOENIX-3953:
------------------------------------
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12885852/PHOENIX-3953_4.x-HBase-0.98_addendum2.patch
against 4.x-HBase-0.98 branch at commit
b46cbd375e3d2ee9a11644825c13937572c027cd.
ATTACHMENT ID: 12885852
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:red}-1 tests included{color}. The patch doesn't appear to include
any new or modified tests.
Please justify why no new tests are needed for this
patch.
Also please list what manual steps were performed to
verify this patch.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:green}+1 release audit{color}. The applied patch does not increase
the total number of release audit warnings.
{color:red}-1 lineLengths{color}. The patch introduces the following lines
longer than 100:
+ public void postCompact(final
ObserverContext<RegionCoprocessorEnvironment> e, final Store store,
+ // Compaction and split upcalls run with the effective user
context of the requesting user.
+ String tableName =
e.getEnvironment().getRegion().getRegionInfo().getTable().getNameAsString();
+ // FIXME: if this is an index on a view, we won't find
a row for it in SYSTEM.CATALOG
+
get.addColumn(PhoenixDatabaseMetaData.TABLE_FAMILY_BYTES,
PhoenixDatabaseMetaData.INDEX_DISABLE_TIMESTAMP_BYTES);
+ disableIndexTimestamp =
PLong.INSTANCE.getCodec().decodeLong(cell.getValueArray(),
cell.getValueOffset(), SortOrder.getDefault());
+ mutationCode =
IndexUtil.updateIndexState(tableKey, 0L, htable,
PIndexState.DISABLE).getMutationCode();
+ } catch (Throwable t) { // log, but swallow exception as
we don't want to impact compaction
+ logger.warn("Potential failure to permanently disable
index during compaction " +
e.getEnvironment().getRegionInfo().getTable().getNameAsString(), t);
+ if (disableIndexTimestamp != 0 && mutationCode !=
MutationCode.TABLE_ALREADY_EXISTS && mutationCode !=
MutationCode.TABLE_NOT_FOUND) {
{color:red}-1 core tests{color}. The patch failed these unit tests:
Test results:
https://builds.apache.org/job/PreCommit-PHOENIX-Build/1401//testReport/
Console output:
https://builds.apache.org/job/PreCommit-PHOENIX-Build/1401//console
This message is automatically generated.
> Clear INDEX_DISABLED_TIMESTAMP and disable index on compaction
> --------------------------------------------------------------
>
> Key: PHOENIX-3953
> URL: https://issues.apache.org/jira/browse/PHOENIX-3953
> Project: Phoenix
> Issue Type: Bug
> Reporter: James Taylor
> Assignee: James Taylor
> Labels: globalMutableSecondaryIndex
> Fix For: 4.12.0
>
> Attachments: PHOENIX-3953_4.x-HBase-0.98_addendum2.patch,
> PHOENIX-3953_addendum1.patch, PHOENIX-3953_addendum2.patch,
> PHOENIX-3953.patch, PHOENIX-3953_v2.patch
>
>
> To guard against a compaction occurring (which would potentially clear delete
> markers and puts that the partial index rebuild process counts on to properly
> catch up an index with the data table), we should clear the
> INDEX_DISABLED_TIMESTAMP and mark the index as disabled. This could be done
> in the post compaction coprocessor hook. At this point, a manual rebuild of
> the index would be required.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
