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

Hudson commented on HBASE-30340:
--------------------------------

Results for branch branch-3
        [build #143 on 
builds.a.o|https://ci-hbase.apache.org/job/HBase-Integration-Test/job/branch-3/143/]:
 (/) *{color:green}+1 overall{color}*
----
details (if available):



(/) {color:green}+1 client integration test for 3.3.5 {color}
(/) {color:green}+1 client integration test for 3.3.5 with shaded hadoop 
client{color}


(/) {color:green}+1 client integration test for 3.3.6 {color}
(/) {color:green}+1 client integration test for 3.3.6 with shaded hadoop 
client{color}


(/) {color:green}+1 client integration test for 3.4.0 {color}
(/) {color:green}+1 client integration test for 3.4.0 with shaded hadoop 
client{color}


(/) {color:green}+1 client integration test for 3.4.1 {color}
(/) {color:green}+1 client integration test for 3.4.1 with shaded hadoop 
client{color}


(/) {color:green}+1 client integration test for 3.4.2 {color}
(/) {color:green}+1 client integration test for 3.4.2 with shaded hadoop 
client{color}


(/) {color:green}+1 client integration test for 3.4.3 {color}
(/) {color:green}+1 client integration test for 3.4.3 with shaded hadoop 
client{color}


> CatalogJanitor can run concurrent scans due to incorrect alreadyRunning lock 
> handling
> -------------------------------------------------------------------------------------
>
>                 Key: HBASE-30340
>                 URL: https://issues.apache.org/jira/browse/HBASE-30340
>             Project: HBase
>          Issue Type: Bug
>          Components: master
>    Affects Versions: 0.90.5
>            Reporter: Sercan Tekin
>            Assignee: Sercan Tekin
>            Priority: Critical
>              Labels: pull-request-available
>             Fix For: 4.0.0-alpha-1, 2.7.0, 3.1.0, 3.0.1, 2.6.8, 2.5.17
>
>
> {{CatalogJanitor.scan()}} can allow concurrent scans due to incorrect 
> handling of the
> {{alreadyRunning}} lock.
> Currently, the lock acquisition is performed inside the {{try}} block:
> {code:java}
>     try {
>       if (!alreadyRunning.compareAndSet(false, true)) {
>         return -1;
>       }
>       ...
>     } finally {
>       alreadyRunning.set(false);
>     }
> {code}
> When a scan is already running, a concurrent scan fails the 
> {{compareAndSet()}} and
> returns immediately. However, because the lock acquisition is inside the 
> {{try}} block,
> the {{finally}} block is still executed and resets {{alreadyRunning}} to 
> false.
> This allows another scan to acquire the lock while the original scan is still 
> running.
> The lock acquisition should be moved before the {{try}} block:
> {code:java}
>     if (!alreadyRunning.compareAndSet(false, true)) {
>       return -1;
>     }
>     try {
>       ...
>     } finally {
>       alreadyRunning.set(false);
>     }
> {code}
> This prevents another scan from starting until the current scan has completed.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Reply via email to