phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hadoop QA (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (PHOENIX-4053) Lock row exclusively when necessary for mutable secondary indexing
Date Sun, 30 Jul 2017 23:29:00 GMT

    [ https://issues.apache.org/jira/browse/PHOENIX-4053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16106695#comment-16106695
] 

Hadoop QA commented on PHOENIX-4053:
------------------------------------

{color:red}-1 overall{color}.  Here are the results of testing the latest attachment 
  http://issues.apache.org/jira/secure/attachment/12879545/PHOENIX-4053_v4.patch
  against master branch at commit 9c458fa3d3ecdeb17de5b717c26cfdea1608c358.
  ATTACHMENT ID: 12879545

    {color:green}+1 @author{color}.  The patch does not contain any @author tags.

    {color:green}+1 tests included{color}.  The patch appears to include 4 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 51 warning messages.

    {color:red}-1 release audit{color}.  The applied patch generated 1 release audit warnings
(more than the master's current 0 warnings).

    {color:red}-1 lineLengths{color}.  The patch introduces the following lines longer than
100:
    +    private static void addDelayingCoprocessor(Connection conn, String tableName) throws
SQLException, IOException {
+        conn.createStatement().execute("CREATE TABLE " + tableName + "(k1 INTEGER NOT NULL,
k2 INTEGER NOT NULL, v1 INTEGER, CONSTRAINT pk PRIMARY KEY (k1,k2))");
+                                props.setProperty(PhoenixRuntime.CURRENT_SCN_ATTRIB, Long.toString(scn));
+                                conn = DriverManager.getConnection(getUrl(), props).unwrap(PhoenixConnection.class);
+                                props.setProperty(PhoenixRuntime.CURRENT_SCN_ATTRIB, Long.toString(scn));
+                                conn = DriverManager.getConnection(getUrl(), props).unwrap(PhoenixConnection.class);
+                                conn.createStatement().execute("UPSERT INTO " + tableName
+ " VALUES (" + (i % 10) + ", 0, 1)");
+        assertTrue("Expected table row count ( " + count1 + ") to match index row count ("
+ count2 + ")", count1 == count2);
+        conn.createStatement().execute("CREATE TABLE " + tableName + "(k1 INTEGER NOT NULL,
k2 INTEGER NOT NULL, v1 INTEGER, CONSTRAINT pk PRIMARY KEY (k1,k2))");
+                        conn.createStatement().execute("UPSERT INTO " + tableName + " VALUES
(" + (i % 10) + ", 0, 1)");

     {color:red}-1 core tests{color}.  The patch failed these unit tests:
     ./phoenix-core/target/failsafe-reports/TEST-org.apache.phoenix.end2end.OnDuplicateKeyIT
./phoenix-core/target/failsafe-reports/TEST-org.apache.phoenix.end2end.ClientTimeArithmeticQueryIT

Test results: https://builds.apache.org/job/PreCommit-PHOENIX-Build/1237//testReport/
Release audit warnings: https://builds.apache.org/job/PreCommit-PHOENIX-Build/1237//artifact/patchprocess/patchReleaseAuditWarnings.txt
Javadoc warnings: https://builds.apache.org/job/PreCommit-PHOENIX-Build/1237//artifact/patchprocess/patchJavadocWarnings.txt
Console output: https://builds.apache.org/job/PreCommit-PHOENIX-Build/1237//console

This message is automatically generated.

> Lock row exclusively when necessary for mutable secondary indexing
> ------------------------------------------------------------------
>
>                 Key: PHOENIX-4053
>                 URL: https://issues.apache.org/jira/browse/PHOENIX-4053
>             Project: Phoenix
>          Issue Type: Bug
>            Reporter: James Taylor
>            Assignee: James Taylor
>         Attachments: PHOENIX-4053_4.x-HBase-0.98_v2.patch, PHOENIX-4053_4.x-HBase-0.98_v3.patch,
PHOENIX-4053-4.x-HBase-0.98_v4.patch, PHOENIX-4053_v2.patch, PHOENIX-4053_v3.patch, PHOENIX-4053_v4.patch,
PHOENIX-4053_wip.patch
>
>
> From HBase 1.2 on, rows are not exclusively locked when the preBatchMutate call is made
(see HBASE-18474). The mutable secondary index (global and local) depend on this to get a
consistent snapshot of a row between the point when the current row value is looked up, and
when the new row is written, until the mvcc is advanced. Otherwise, a subsequent update to
a row may not see the current row state. Even with pre HBase 1.2 releases, the lock isn't
held long enough for us. We need to hold the locks from the start of the preBatchMutate (when
we read the data table to get the prior row values) until the mvcc is advanced (beginning
of postBatchMutateIndispensably).
> Given the above, it's best if Phoenix manages the row locking itself (mimicing the current
HBase mechanism).



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Mime
View raw message