You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@phoenix.apache.org by "Hadoop QA (JIRA)" <ji...@apache.org> on 2016/02/14 18:58:18 UTC

[jira] [Commented] (PHOENIX-2221) Option to make data regions not writable when index regions are not available

    [ 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)