accumulo-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (ACCUMULO-3509) Scanner lock cause Tablet lock, hence preventing idle scans from being swept, hence blocking SimpleTimer thread
Date Mon, 04 Jan 2016 16:59:40 GMT

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

ASF GitHub Bot commented on ACCUMULO-3509:
------------------------------------------

Github user keith-turner commented on a diff in the pull request:

    https://github.com/apache/accumulo/pull/60#discussion_r48752641
  
    --- Diff: server/tserver/src/main/java/org/apache/accumulo/tserver/tablet/Scanner.java
---
    @@ -38,100 +40,126 @@
       private ScanDataSource isolatedDataSource;
       private boolean sawException = false;
       private boolean scanClosed = false;
    +  protected Semaphore scannerSemaphore;
     
       Scanner(Tablet tablet, Range range, ScanOptions options) {
         this.tablet = tablet;
         this.range = range;
         this.options = options;
    +    scannerSemaphore = new Semaphore(1, true);
    --- End diff --
    
    This semaphore replaces a synchronized block with a fair semaphore.  AFAICT from searching
around on the web, synchronized blocks are not fair.   Do we need fairness here?  The javadocs
say its more expensive.   If its not needed, not sure should set it.
    
    I was trying to determine the difference between the semaphore and a lock for this case.
 It seems like the only difference is re-entrance, which it does not seem is needed in this
case.


> Scanner lock cause Tablet lock, hence preventing idle scans from being swept, hence blocking
SimpleTimer thread 
> ----------------------------------------------------------------------------------------------------------------
>
>                 Key: ACCUMULO-3509
>                 URL: https://issues.apache.org/jira/browse/ACCUMULO-3509
>             Project: Accumulo
>          Issue Type: Bug
>          Components: tserver
>    Affects Versions: 1.6.0
>            Reporter: marco polo
>            Assignee: marco polo
>             Fix For: 1.6.5, 1.7.1, 1.8.0
>
>
> Synchronization with Tablet$Scanner via a read() will block close() being called via
the sweep method in TabletServer. As a result, the SimpleTimer thread does not continue, and
idle threads grow until the scan completes. 
> My patch, which is forthcoming, converts synchronized methods to use a fair lock. If
the lock is held by a read call, the close call will attempt to obtain it, time out, and return
indicating a close was not successful. The sweep will continue, and the SimpleTimer thread
will respawn later, attempting closure on those Tablets at a later time. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message