[
https://issues.apache.org/jira/browse/HBASE-15398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15203654#comment-15203654
]
Anoop Sam John commented on HBASE-15398:
----------------------------------------
Checking the code
{code}
if (hasFilterRow) {
if (LOG.isTraceEnabled()) {
LOG.trace("filter#hasFilterRow is true which prevents partial
results from being "
+ " formed. Changing scope of limits that may create partials");
}
scannerContext.setSizeLimitScope(LimitScope.BETWEEN_ROWS);
scannerContext.setTimeLimitScope(LimitScope.BETWEEN_ROWS);
}
{code}
So because of this limit scope set, we say we don't allow in btw ROW return.
Ya make sense.
But is that only for cells from essential family? I dont mean in code. This is
what we wanted?
Because I can see that we call the Filter filterRowCells() and filterRow() once
we read cells from all essential families. ie. storeHeap
After this only we go ahead with the joinedHeap.
When we consider SCVF, yes it is fine. For the decision making of whether a
Row to be included or not, the cells from essential family is enough.
That means when we read cells from essential families we dont allow to reach
any limit ie. size or time or batch. But after that it is allowed. At least
as per the other code parts. But I can not see we reset the setTimeLimitScope.
Now we need to decide what is correct. I think it make sense to call the
filter methods after read from storeHeap.
> Cells loss or disorder when using family essential filter and partial
> scanning protocol
> ---------------------------------------------------------------------------------------
>
> Key: HBASE-15398
> URL: https://issues.apache.org/jira/browse/HBASE-15398
> Project: HBase
> Issue Type: Bug
> Components: dataloss, Scanners
> Affects Versions: 1.2.0, 1.1.3
> Reporter: Phil Yang
> Assignee: Phil Yang
> Priority: Critical
> Attachments: 15398-test.txt, HBASE-15398-v2.patch,
> HBASE-15398-v3.patch, HBASE-15398-v4.patch, HBASE-15398-v5.patch,
> HBASE-15398.v1.txt
>
>
> In RegionScannerImpl, we have two heaps, storeHeap and joinedHeap. If we have
> a filter and it doesn't apply to all cf, the stores whose families needn't be
> filtered will be in joinedHeap. We scan storeHeap first, then joinedHeap,
> and merge the results and sort and return to client. We need sort because the
> order of Cell is rowkey/cf/cq/ts and a smaller cf may be in the joinedHeap.
> However, after HBASE-11544 we may transfer partial results when we get
> SIZE_LIMIT_REACHED_MID_ROW or other similar states. We may return a larger cf
> first because it is in storeHeap and then a smaller cf because it is in
> joinedHeap. Server won't hold all cells in a row and client doesn't have a
> sorting logic. The order of cf in Result for user is wrong.
> And a more critical bug is, if we get a LIMIT_REACHED_MID_ROW on the last
> cell of a row in storeHeap, we will break scanning in RegionScannerImpl and
> in populateResult we will change the state to SIZE_LIMIT_REACHED because next
> peeked cell is next row. But this is only the last cell of one and we have
> two... And SIZE_LIMIT_REACHED means this Result is not partial (by
> ScannerContext.partialResultFormed), client will see it and merge them and
> return to user with losing data of joinedHeap. On next scan we will read next
> row of storeHeap and joinedHeap is forgotten and never be read...
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
