[
https://issues.apache.org/jira/browse/PHOENIX-7024?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17757731#comment-17757731
]
ASF GitHub Bot commented on PHOENIX-7024:
-----------------------------------------
kadirozde commented on code in PR #1659:
URL: https://github.com/apache/phoenix/pull/1659#discussion_r1302274816
##########
phoenix-core/src/main/java/org/apache/phoenix/iterate/NonAggregateRegionScannerFactory.java:
##########
@@ -303,12 +282,34 @@ public boolean isFilterDone() {
@Override
public boolean next(List<Cell> results) throws IOException {
try {
- if (isFilterDone()) { return false; }
- for (int i = 0; i < tuple.size(); i++) {
- results.add(tuple.getValue(i));
- }
tuple = iterator.next();
- return !isFilterDone();
+ if (isFilterDone()) {
+ if ((iterator.getRemainingOffset() > 0 ||
!foundNonDummyRow) && !lastScan) {
+ // we set a special cell in the result to track
the offset across
+ // region boundaries. This cell is set when we
reach the end of the
+ // region and the offset remaining > 0 OR the
offset became 0, but we
+ // reached the end of the region without finding
any valid (non dummy)
+ // rows. We couldn't find valid rows either
because of paging or
+ // because of some filter. The client in
SerialIterator expects this
+ // cell as the only row in the result set. If this
cell is sent along
+ // with any additional rows then this special cell
is treated as part
+ // of application result set.
+ KeyValue kv = new
KeyValue(QueryConstants.OFFSET_ROW_KEY_BYTES,
+ QueryConstants.OFFSET_FAMILY,
QueryConstants.OFFSET_COLUMN,
+
PInteger.INSTANCE.toBytes(iterator.getRemainingOffset()));
+ results.add(kv);
+ }
+ return false;
+ } else {
+ // tuple is non null
Review Comment:
We do not handle the case where the region closes before returning the row
at the starting offset. To support this, we need to get the region lock using
region.startRegionOperation() while scanning the rows before the starting
offset. If we get a dummy row while the region is locked (i.e., while scanning
the rows before the starting offset), we need to close the region and return a
special result (not dummy) which includes the current row key and the remaining
offset. The client should reopen a scanner with starting with the next row and
pass the remaining offset.
> Issues in ServerPaging
> ----------------------
>
> Key: PHOENIX-7024
> URL: https://issues.apache.org/jira/browse/PHOENIX-7024
> Project: Phoenix
> Issue Type: Bug
> Affects Versions: 4.16.0, 5.2.0, 5.1.3
> Reporter: Tanuj Khurana
> Assignee: Tanuj Khurana
> Priority: Major
>
> While testing server side paging introduced in PHOENIX-6211 , I set the
> config *phoenix.server.page.size.ms* to 0. This effectively will page 1 row
> at a time and serves as a good stress test for the paging code. During the
> process, I hit multiple issues which I will address in this JIRA.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
