[ https://issues.apache.org/jira/browse/ACCUMULO-3509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15081330#comment-15081330 ]
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_r48749879 --- 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); } - public synchronized ScanBatch read() throws IOException, TabletClosedException { - - if (sawException) - throw new IllegalStateException("Tried to use scanner after exception occurred."); + public ScanBatch read() throws IOException, TabletClosedException { if (scanClosed) --- End diff -- Below is from the semaphore javadoc. Reading that is sounds like there is no guarantee of seeing a change to `scanClosed` until after `acquire()`. ``` Memory consistency effects: Actions in a thread prior to calling a "release" method such as release() happen-before actions following a successful "acquire" method such as acquire() in another thread. ``` > 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)