[
https://issues.apache.org/jira/browse/PHOENIX-2221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15146668#comment-15146668
]
Hadoop QA commented on PHOENIX-2221:
------------------------------------
{color:red}-1 overall{color}. Here are the results of testing the latest
attachment
http://issues.apache.org/jira/secure/attachment/12787869/PHOENIX-2221-v8.patch
against master branch at commit cdaca287cd50fbdd25a9b11d8af6fb0a3b3956cc.
ATTACHMENT ID: 12787869
{color:green}+1 @author{color}. The patch does not contain any @author
tags.
{color:green}+1 tests included{color}. The patch appears to include 3 new
or modified tests.
{color:green}+1 javac{color}. The applied patch does not increase the
total number of javac compiler warnings.
{color:red}-1 javadoc{color}. The javadoc tool appears to have generated
19 warning messages.
{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:
+ "CREATE TABLE " + fullTableName + " (k VARCHAR NOT
NULL PRIMARY KEY, v1 VARCHAR, v2 VARCHAR)");
+
assertEquals(SQLExceptionCode.INDEX_FAILURE_BLOCK_WRITE.getErrorCode(),
e.getErrorCode());
+ private static boolean hasIndexDisableTimestamp(Connection conn, String
indexName) throws SQLException {
+ ResultSet rs = conn.createStatement().executeQuery("SELECT " +
PhoenixDatabaseMetaData.INDEX_DISABLE_TIMESTAMP +
+ left.rowKeyOrderOptimizable(), left.isTransactional(),
left.getUpdateCacheFrequency(), left.getIndexDisableTimestamp());
+ table.getIndexType(), table.rowKeyOrderOptimizable(),
table.isTransactional(), table.getUpdateCacheFrequency(),
table.getIndexDisableTimestamp());
+ null, table.rowKeyOrderOptimizable(),
table.isTransactional(), table.getUpdateCacheFrequency(),
table.getIndexDisableTimestamp());
+ true, null, null, null, true, true, true, null, null,
null, false, false, 0, 0L);
+ private static final int INDEX_DISABLE_TIMESTAMP =
TABLE_KV_COLUMNS.indexOf(INDEX_DISABLE_TIMESTAMP_KV);
+ long minNonZerodisableIndexTimestamp = disableIndexTimestamp > 0 ?
disableIndexTimestamp : Long.MAX_VALUE;
{color:red}-1 core tests{color}. The patch failed these unit tests:
./phoenix-core/target/failsafe-reports/TEST-org.apache.phoenix.end2end.index.MutableIndexFailureIT
./phoenix-core/target/failsafe-reports/TEST-org.apache.phoenix.end2end.index.ReadOnlyIndexFailureIT
Test results:
https://builds.apache.org/job/PreCommit-PHOENIX-Build/257//testReport/
Javadoc warnings:
https://builds.apache.org/job/PreCommit-PHOENIX-Build/257//artifact/patchprocess/patchJavadocWarnings.txt
Console output:
https://builds.apache.org/job/PreCommit-PHOENIX-Build/257//console
This message is automatically generated.
> 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: James Taylor
> Fix For: 4.8.0
>
> Attachments: 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-v7.patch, PHOENIX-2221-v8.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)
