You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@phoenix.apache.org by "Chao Wang (Jira)" <ji...@apache.org> on 2020/04/21 03:43:00 UTC

[jira] [Created] (PHOENIX-5860) Throw exception which region is closing or splitting when delete data

Chao Wang created PHOENIX-5860:
----------------------------------

             Summary: Throw exception which region is closing or splitting when delete data
                 Key: PHOENIX-5860
                 URL: https://issues.apache.org/jira/browse/PHOENIX-5860
             Project: Phoenix
          Issue Type: Bug
          Components: core
    Affects Versions: 4.13.1
            Reporter: Chao Wang
         Attachments: PHOENIX.4.13.x-HBASE-1.3.x.001.patch

Currently delete data is UngroupedAggregateRegionObserver class  on server side, this class check if isRegionClosingOrSplitting is true. when isRegionClosingOrSplitting is true, will throw new IOException("Temporarily unable to write from scan because region is closing or splitting"). 

when region online , which initialize phoenix CP that isRegionClosingOrSplitting  is false.before region split, region change  isRegionClosingOrSplitting to true.but if region split failed,split will roll back where not change   isRegionClosingOrSplitting  to false. after that all write  opration will always throw exception which is Temporarily unable to write from scan because region is closing or splitting。

so we should change isRegionClosingOrSplitting   to false  when region preRollBackSplit in UngroupedAggregateRegionObserver class。

A simple test where a data table split failed, then roll back success.but delete data always throw exception.
 # create data table 
 # bulkload data for this table
 # alter hbase-server code, which region split will throw exception , then rollback.
 # use hbase shell , split region
 # view regionserver log, where region split failed, and then rollback success.
 # user phoenix sqlline.py for delete data, which  will throw exption

 

 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)