[
https://issues.apache.org/jira/browse/PHOENIX-5137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kiran Kumar Maturi updated PHOENIX-5137:
----------------------------------------
Description:
[~lhofhansl] [~vincentpoon] [~tdsilva] please review
In order to differentiate between the index rebuilder retries
(UngroupedAggregateRegionObserver.rebuildIndices()) and commits that happen in
the loop of UngroupedAggregateRegionObserver.doPostScannerOpen() as part of
PHOENIX-4600 blockingMemstoreSize was set to -1 for rebuildIndices;
{code:java}
commitBatchWithRetries(region, mutations, -1);{code}
blocks the region split as the check for region closing does not happen
blockingMemstoreSize > 0
{code:java}
for (int i = 0; blockingMemstoreSize > 0 && region.getMemstoreSize() >
blockingMemstoreSize && i < 30; i++) {
try{
checkForRegionClosing();
....
{code}
Plan is to have the check for region closing at least once before committing
the batch
{code:java}
checkForRegionClosing();
for (int i = 0; blockingMemstoreSize > 0 && region.getMemstoreSize() >
blockingMemstoreSize && i < 30; i++) {
try{
checkForRegionClosing();
....
{code}
Steps to reproduce
1. Create a table with one index (startime)
2. Add 1-2 million rows
3. Wait till the index is active
4. Disable the index with start time (noted in step 1)
5. Once the rebuilder starts split data table region
Repeat the steps again after applying the patch to check the difference.
was:
[~lhofhansl] [~vincentpoon] [~tdsilva] please review
In order to differentiate between the index rebuilder retries
(UngroupedAggregateRegionObserver.rebuildIndices()) and commits that happen in
the loop of UngroupedAggregateRegionObserver.doPostScannerOpen() as part of
PHOENIX-4600 blockingMemstoreSize was set to -1 for rebuildIndices;
{code:java}
commitBatchWithRetries(region, mutations, -1);{code}
blocks the region split as the check for region closing does not happen
blockingMemstoreSize > 0
{code:java}
for (int i = 0; blockingMemstoreSize > 0 && region.getMemstoreSize() >
blockingMemstoreSize && i < 30; i++) {
try{
checkForRegionClosing();
....
{code}
Plan is to have the check for region closing at least once before committing
the batch
{code:java}
checkForRegionClosing();
for (int i = 0; blockingMemstoreSize > 0 && region.getMemstoreSize() >
blockingMemstoreSize && i < 30; i++) {
try{
checkForRegionClosing();
....
{code}
> Index Rebuilder scan increases data table region split time
> -----------------------------------------------------------
>
> Key: PHOENIX-5137
> URL: https://issues.apache.org/jira/browse/PHOENIX-5137
> Project: Phoenix
> Issue Type: Bug
> Affects Versions: 4.14.1
> Reporter: Kiran Kumar Maturi
> Assignee: Kiran Kumar Maturi
> Priority: Major
> Attachments: PHOENIX-5137-4.14-Hbase-1.3.01.patch,
> PHOENIX-5137-4.14-Hbase-1.3.01.patch
>
>
> [~lhofhansl] [~vincentpoon] [~tdsilva] please review
> In order to differentiate between the index rebuilder retries
> (UngroupedAggregateRegionObserver.rebuildIndices()) and commits that happen
> in the loop of UngroupedAggregateRegionObserver.doPostScannerOpen() as part
> of PHOENIX-4600 blockingMemstoreSize was set to -1 for rebuildIndices;
> {code:java}
> commitBatchWithRetries(region, mutations, -1);{code}
> blocks the region split as the check for region closing does not happen
> blockingMemstoreSize > 0
> {code:java}
> for (int i = 0; blockingMemstoreSize > 0 && region.getMemstoreSize() >
> blockingMemstoreSize && i < 30; i++) {
> try{
> checkForRegionClosing();
> ....
> {code}
> Plan is to have the check for region closing at least once before committing
> the batch
> {code:java}
> checkForRegionClosing();
> for (int i = 0; blockingMemstoreSize > 0 && region.getMemstoreSize() >
> blockingMemstoreSize && i < 30; i++) {
> try{
> checkForRegionClosing();
> ....
> {code}
> Steps to reproduce
> 1. Create a table with one index (startime)
> 2. Add 1-2 million rows
> 3. Wait till the index is active
> 4. Disable the index with start time (noted in step 1)
> 5. Once the rebuilder starts split data table region
> Repeat the steps again after applying the patch to check the difference.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
