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

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

Github user phrocker commented on a diff in the pull request:

    https://github.com/apache/accumulo/pull/60#discussion_r48753072
  
    --- 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 --
    
    My only reason for enforcing fairness was that we likely only have a single 
thread doing reads ( otherwise we'd have different sessions ); however, we will 
have another thread doing a close. I wanted to enforce order in the event that 
the read should occur first. In rethinking this I'm not terribly certain this a 
problem. 
    
    As we discussed I only used a semaphore based on the aforementioned 
assumption of a single thread doing reads within the scanner. I'm not tied to 
the idea. 


> 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