You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hbase.apache.org by "Jim Kellerman (JIRA)" <ji...@apache.org> on 2008/06/28 01:05:44 UTC
[jira] Created: (HBASE-716) TestGet2.testGetClosestBefore fails
with hadoop-0.17.1
TestGet2.testGetClosestBefore fails with hadoop-0.17.1
------------------------------------------------------
Key: HBASE-716
URL: https://issues.apache.org/jira/browse/HBASE-716
Project: Hadoop HBase
Issue Type: Bug
Components: regionserver
Affects Versions: 0.2.0
Reporter: Jim Kellerman
Fix For: 0.2.0
TestGet2.testGetClosestBefore fails with hadoop-0.17.1
After the rows are flushed to a MapFile, we get no result when we try to find the closest row before 038. We find 035, but that is deleted. So we advance, the next record is 040 which is after 038 and we give up. This results in a null result being passed back to the test which then dies with an NPE because it expects that getClosestRowBefore should find row 030.
It appears that there is no logic to back up from a candidate row if the candidate came before the desired key but is deleted. We should find the row before.
I'm guessing that this is failing because hadoop-0.17.1 incorporates HADOOP-3472 (MapFile.Reader getClosest() function returns incorrect results when before is true)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (HBASE-716) TestGet2.testGetClosestBefore fails
with hadoop-0.17.1
Posted by "Jim Kellerman (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HBASE-716?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jim Kellerman resolved HBASE-716.
---------------------------------
Resolution: Fixed
Change works with both hadoop 0.17.0 and 0.17.1
> TestGet2.testGetClosestBefore fails with hadoop-0.17.1
> ------------------------------------------------------
>
> Key: HBASE-716
> URL: https://issues.apache.org/jira/browse/HBASE-716
> Project: Hadoop HBase
> Issue Type: Bug
> Components: regionserver
> Affects Versions: 0.2.0
> Reporter: Jim Kellerman
> Assignee: Jim Kellerman
> Fix For: 0.2.0
>
>
> TestGet2.testGetClosestBefore fails with hadoop-0.17.1
> After the rows are flushed to a MapFile, we get no result when we try to find the closest row before 038. We find 035, but that is deleted. So we advance, the next record is 040 which is after 038 and we give up. This results in a null result being passed back to the test which then dies with an NPE because it expects that getClosestRowBefore should find row 030.
> It appears that there is no logic to back up from a candidate row if the candidate came before the desired key but is deleted. We should find the row before.
> I'm guessing that this is failing because hadoop-0.17.1 incorporates HADOOP-3472 (MapFile.Reader getClosest() function returns incorrect results when before is true)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (HBASE-716) TestGet2.testGetClosestBefore fails
with hadoop-0.17.1
Posted by "Jim Kellerman (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/HBASE-716?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jim Kellerman reassigned HBASE-716:
-----------------------------------
Assignee: Jim Kellerman
> TestGet2.testGetClosestBefore fails with hadoop-0.17.1
> ------------------------------------------------------
>
> Key: HBASE-716
> URL: https://issues.apache.org/jira/browse/HBASE-716
> Project: Hadoop HBase
> Issue Type: Bug
> Components: regionserver
> Affects Versions: 0.2.0
> Reporter: Jim Kellerman
> Assignee: Jim Kellerman
> Fix For: 0.2.0
>
>
> TestGet2.testGetClosestBefore fails with hadoop-0.17.1
> After the rows are flushed to a MapFile, we get no result when we try to find the closest row before 038. We find 035, but that is deleted. So we advance, the next record is 040 which is after 038 and we give up. This results in a null result being passed back to the test which then dies with an NPE because it expects that getClosestRowBefore should find row 030.
> It appears that there is no logic to back up from a candidate row if the candidate came before the desired key but is deleted. We should find the row before.
> I'm guessing that this is failing because hadoop-0.17.1 incorporates HADOOP-3472 (MapFile.Reader getClosest() function returns incorrect results when before is true)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.