hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "stack (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-14689) Addendum and unit test for HBASE-13471
Date Thu, 18 May 2017 07:17:04 GMT

    [ https://issues.apache.org/jira/browse/HBASE-14689?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16015319#comment-16015319

stack commented on HBASE-14689:

Looking more, it seems that the right patch got applied to 1.2; we just remove the assert.
So ignore the above.

For completeness, here is what got applied....

commit 1862b58425ba639e1969e0e4aca1f2a8c53dadfe
Author: Enis Soztutar <enis@apache.org>
Date:   Tue Nov 24 19:15:09 2015 -0800

    HBASE-14689 Addendum and unit test for HBASE-13471

diff --git a/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java
index d851904dcf..f86b3cc192 100644
--- a/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java
+++ b/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/HRegion.java
@@ -3003,7 +3003,6 @@ public class HRegion implements HeapSize, PropagatingConfigurationObserver,
         if (rowLock == null) {
           // We failed to grab another lock
-          assert false: "Should never fail to get lock when blocking";
           break; // stop acquiring more rows for this batch
         } else {

The culprit, in branch-1.2 (and in Master branch), that drops the optimization is this one:

commit bae2a970817d3693946c5b1d4e2382e56b1e94b8
Author: stack <stack@apache.org>
Date:   Wed Sep 30 11:48:46 2015 -0700

    HBASE-14465 Backport 'Allow rowlock to be reader/write' to branch-1


It is backport of HBASE-12751. It includes the drop-of-the-optimization that is on the 1.1
branch attached here. The change shows up in v14 of the HBASE-12751 patch here:

hadoopqa Hadoop QA added a comment - 22/Jul/15 14:12
-1 overall. Here are the results of testing the latest attachment 
against master branch at commit 5ec5552be0534dbf4b07ef6607741ae6f9ab0495.

Will do some more profiling to see if this dropped optimization root cause or partial cause
of the issues I'm seeing....

> Addendum and unit test for HBASE-13471
> --------------------------------------
>                 Key: HBASE-14689
>                 URL: https://issues.apache.org/jira/browse/HBASE-14689
>             Project: HBase
>          Issue Type: Bug
>            Reporter: Enis Soztutar
>            Assignee: Enis Soztutar
>             Fix For: 2.0.0, 1.2.0, 1.3.0, 1.0.3, 1.1.3, 0.98.16, 0.98.17
>         Attachments: hbase-14689-after-revert.patch, hbase-14689-after-revert.patch,
hbase-14689_v1-branch-1.1.patch, hbase-14689_v1-branch-1.1.patch, hbase-14689_v1.patch
> One of our customers ran into HBASE-13471, which resulted in all the handlers getting
blocked and various other issues. While backporting the issue, I noticed that there is one
more case where we might go into infinite loop. In case a row lock cannot be acquired (due
to a previous leak for example which we have seen in Phoenix before) this will cause similar
infinite loop. 

This message was sent by Atlassian JIRA

View raw message