[ https://issues.apache.org/jira/browse/PHOENIX-4018?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16089865#comment-16089865 ]
Ankit Singhal commented on PHOENIX-4018: ---------------------------------------- Yes, only last scanner should update the progress(which you can do easily in BaseScannerRegionObserver.RegionScannerHolder#next(List<Cell>,ScannerContext)), HeartBeat will also work fine if we do update the time progress in the same manner. > HashJoin may produce nulls for LHS table columns > ------------------------------------------------ > > Key: PHOENIX-4018 > URL: https://issues.apache.org/jira/browse/PHOENIX-4018 > Project: Phoenix > Issue Type: Bug > Affects Versions: 4.11.0 > Reporter: Sergey Soldatov > Assignee: Sergey Soldatov > Priority: Critical > Attachments: PHOENIX-4018-1.patch > > > Here is the problem: in HashJoinRegionScanner methods (nextRow for example) > we are using the same scanner context that was created in RSRpcServices. It > has limits (i.e. 2Mb size). Let's say that we have 3Mb region and the only > key that match the join condition is located at the end of the region. In > HashJoinRegionScanner#nextRow when we iterate through the region rows once we > reached the limit of 2Mb, every region scanner nextRow will return a single > cell and the scanner context will have SIZE_LIMIT_REACHED_MID_ROW state. But > we don't have any logic that check that, so this single cell is considered as > a complete row with all nulls except one column. > How to fix it: > 1. for region scanner we may provide NoLimitScannerContext, so we will never > get a partial result. > 2. We need to update the scanner context that we got from RSRpcServices with > the real data, basing on the size of results we are going to return. -- This message was sent by Atlassian JIRA (v6.4.14#64029)