hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ted Yu (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-14497) Reverse Scan threw StackOverflow caused by readPt checking
Date Tue, 06 Oct 2015 20:54:27 GMT

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

Ted Yu commented on HBASE-14497:
--------------------------------

Test suite passed:
{code}
Fetching https://builds.apache.org/job/PreCommit-HBASE-Build/15885/consoleFull
Building remotely on <a href='/computer/H0' class='model-link'>H0</a> (Hadoop
Tez) in workspace /home/jenkins/jenkins-slave/workspace/PreCommit-HBASE-Build
Testing patch for HBASE-14497.
Testing patch on branch branch-1.
[INFO] Apache HBase ...................................... SUCCESS [2.722s]
[INFO] Apache HBase - Checkstyle ......................... SUCCESS [0.509s]
[INFO] Apache HBase - Resource Bundle .................... SUCCESS [0.162s]
[INFO] Apache HBase - Annotations ........................ SUCCESS [0.911s]
[INFO] Apache HBase - Protocol ........................... SUCCESS [11.037s]
[INFO] Apache HBase - Common ............................. SUCCESS [1:28.402s]
[INFO] Apache HBase - Procedure .......................... SUCCESS [1:52.825s]
[INFO] Apache HBase - Client ............................. SUCCESS [1:20.748s]
[INFO] Apache HBase - Hadoop Compatibility ............... SUCCESS [7.393s]
[INFO] Apache HBase - Hadoop Two Compatibility ........... SUCCESS [7.066s]
[INFO] Apache HBase - Prefix Tree ........................ SUCCESS [9.676s]
[INFO] Apache HBase - Server ............................. SUCCESS [1:36:58.528s]
[INFO] Apache HBase - Testing Util ....................... SUCCESS [1.222s]
[INFO] Apache HBase - Thrift ............................. SUCCESS [3:20.890s]
[INFO] Apache HBase - Rest ............................... SUCCESS [9:11.530s]
[INFO] Apache HBase - Shell .............................. SUCCESS [5:26.924s]
[INFO] Apache HBase - Integration Tests .................. SUCCESS [1.363s]
[INFO] Apache HBase - Examples ........................... SUCCESS [8.626s]
[INFO] Apache HBase - External Block Cache ............... SUCCESS [0.606s]
[INFO] Apache HBase - Assembly ........................... SUCCESS [1.394s]
[INFO] Apache HBase - Shaded ............................. SUCCESS [0.083s]
[INFO] Apache HBase - Shaded - Client .................... SUCCESS [0.359s]
[INFO] Apache HBase - Shaded - Server .................... SUCCESS [0.483s]
Printing hanging tests
Printing Failing tests
{code}

> Reverse Scan threw StackOverflow caused by readPt checking
> ----------------------------------------------------------
>
>                 Key: HBASE-14497
>                 URL: https://issues.apache.org/jira/browse/HBASE-14497
>             Project: HBase
>          Issue Type: Bug
>    Affects Versions: 2.0.0, 0.98.14, 1.3.0
>            Reporter: Yerui Sun
>            Assignee: Yerui Sun
>             Fix For: 2.0.0
>
>         Attachments: 14497-branch-1-v6.patch, 14497-master-v6.patch, HBASE-14497-0.98.patch,
HBASE-14497-branch-1-v2.patch, HBASE-14497-branch-1-v3.patch, HBASE-14497-branch-1-v6.patch,
HBASE-14497-branch-1.patch, HBASE-14497-master-v2.patch, HBASE-14497-master-v3.patch, HBASE-14497-master-v3.patch,
HBASE-14497-master-v4.patch, HBASE-14497-master-v5.patch, HBASE-14497-master.patch
>
>
> I met stack overflow error in StoreFileScanner.seekToPreviousRow using reversed scan.
I searched and founded HBASE-14155, but it seems to be a different reason.
> The seekToPreviousRow will fetch the row which closest before, and compare mvcc to the
readPt, which acquired when scanner created. If the row's mvcc is bigger than readPt, an recursive
call of seekToPreviousRow will invoked, to find the next closest before row.
> Considering we created a scanner for reversed scan, and some data with smaller rows was
written and flushed, before calling scanner next. When seekToPreviousRow was invoked, it would
call itself recursively, until all rows which written after scanner created were iterated.
The depth of recursive calling stack depends on the count of rows, the stack overflow error
will be threw if the count of rows is large, like 10000.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message