[ 
https://issues.apache.org/jira/browse/HBASE-2228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12918335#action_12918335
 ] 

Nicolas Spiegelberg commented on HBASE-2228:
--------------------------------------------

After further investigation, this is indeed fixed due to HBASE-3043.  
CloseRegionHandler.process() merely sets the ZK status and calls 
HRegion.close().  This section of code is the same section that handles 
compaction abort during system stops.  Might be nice to add a unit test a 
generic region close to make sure that we don't have a regression, but the 
functionality is in place.

> Region close needs to be  fast; e.g. if compacting, abandon it
> --------------------------------------------------------------
>
>                 Key: HBASE-2228
>                 URL: https://issues.apache.org/jira/browse/HBASE-2228
>             Project: HBase
>          Issue Type: Bug
>            Reporter: stack
>
> Over last week or so i've seen slow closes cause regions be off line for a 
> good amount of time. Just now, i saw a big compaction go into effect because 
> "too many store files".  This compaction took nearly two minutes on loaded 
> server.  But during this time flushing was held up.  When the order to close 
> came in (overloaded), we started the close -- so incoming writes were 
> rejected -- but then we had to wait on the compaction to finish before the 
> close went ahead... though incoming clients by now are being turned away.  
> Eventually the compaction completed and then the held-up flush was allowed 
> run..... 91M in about 5 seconds.  Only now was the close allowed complete and 
> the region deployed elsewhere.
> Another time I saw the flush take a good long time because hdfs was running 
> slow.  Probably not much we can do about this one but we should at least look 
> into the above.  Interrupt an ongoing compaction and abandon it... or else 
> keep region open while the compaction is going on and only when compete, then 
> start up the close (Would require new state of CLOSING keeping up a 
> progressable with the master).

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply via email to