[ 
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)

Reply via email to