[
https://issues.apache.org/jira/browse/ACCUMULO-3509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15081675#comment-15081675
]
ASF GitHub Bot commented on ACCUMULO-3509:
------------------------------------------
Github user joshelser commented on a diff in the pull request:
https://github.com/apache/accumulo/pull/62#discussion_r48773083
--- Diff:
server/tserver/src/main/java/org/apache/accumulo/tserver/Tablet.java ---
@@ -1761,33 +1763,41 @@ Scanner createScanner(Range range, int num,
Set<Column> columns, Authorizations
private ScanDataSource isolatedDataSource;
private boolean sawException = false;
private boolean scanClosed = false;
+ private Semaphore scannerSemaphore;
Scanner(Range range, ScanOptions options) {
this.range = range;
this.options = options;
+ scannerSemaphore = new Semaphore(1, true);
}
- synchronized ScanBatch read() throws IOException,
TabletClosedException {
+ ScanBatch read() throws IOException, TabletClosedException {
- if (sawException)
- throw new IllegalStateException("Tried to use scanner after
exception occurred.");
-
- if (scanClosed)
- throw new IllegalStateException("Tried to use scanner after it was
closed.");
+ ScanDataSource dataSource = null;
Batch results = null;
- ScanDataSource dataSource;
+ try {
- if (options.isolated) {
- if (isolatedDataSource == null)
- isolatedDataSource = new ScanDataSource(options);
- dataSource = isolatedDataSource;
- } else {
- dataSource = new ScanDataSource(options);
- }
+ try {
+ scannerSemaphore.acquire();
+ } catch (InterruptedException e) {
+ sawException = true;
+ }
- try {
+ if (sawException)
+ throw new IllegalStateException("Tried to use scanner after
exception occurred.");
--- End diff --
Isn't this exception message a little misleading now if we catch the
InterruptedException above? Would it be better to throw an ISE from the catch
block above with a better message? Or, do we not care what exception we saw?
> 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)
