[ https://issues.apache.org/jira/browse/PHOENIX-4053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16106744#comment-16106744 ]
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/12879549/PHOENIX-4053_v5.patch against master branch at commit 9c458fa3d3ecdeb17de5b717c26cfdea1608c358. ATTACHMENT ID: 12879549 {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: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: + 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.RowValueConstructorIT ./phoenix-core/target/failsafe-reports/TEST-org.apache.phoenix.end2end.index.MutableIndexFailureIT ./phoenix-core/target/failsafe-reports/TEST-org.apache.phoenix.end2end.ScanQueryIT ./phoenix-core/target/failsafe-reports/TEST-org.apache.phoenix.end2end.ClientTimeArithmeticQueryIT Test results: https://builds.apache.org/job/PreCommit-PHOENIX-Build/1239//testReport/ Javadoc warnings: https://builds.apache.org/job/PreCommit-PHOENIX-Build/1239//artifact/patchprocess/patchJavadocWarnings.txt Console output: https://builds.apache.org/job/PreCommit-PHOENIX-Build/1239//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_v5.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)