[jira] [Commented] (ACCUMULO-3509) Scanner lock cause Tablet lock, hence preventing idle scans from being swept, hence blocking SimpleTimer thread
[ https://issues.apache.org/jira/browse/ACCUMULO-3509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14617565#comment-14617565 ] John Vines commented on ACCUMULO-3509: -- Any updates? > 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.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)
[jira] [Commented] (ACCUMULO-3509) Scanner lock cause Tablet lock, hence preventing idle scans from being swept, hence blocking SimpleTimer thread
[ https://issues.apache.org/jira/browse/ACCUMULO-3509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14639240#comment-14639240 ] marco polo commented on ACCUMULO-3509: -- yes, I've tested at a large scale works well. I will be submitted a pull request ASAP > 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.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)
[jira] [Commented] (ACCUMULO-3509) Scanner lock cause Tablet lock, hence preventing idle scans from being swept, hence blocking SimpleTimer thread
[ https://issues.apache.org/jira/browse/ACCUMULO-3509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15060694#comment-15060694 ] Christopher Tubbs commented on ACCUMULO-3509: - Ping for update. Do you have the PR available? > 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.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)
[jira] [Commented] (ACCUMULO-3509) Scanner lock cause Tablet lock, hence preventing idle scans from being swept, hence blocking SimpleTimer thread
[ https://issues.apache.org/jira/browse/ACCUMULO-3509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15076216#comment-15076216 ] ASF GitHub Bot commented on ACCUMULO-3509: -- GitHub user phrocker opened a pull request: https://github.com/apache/accumulo/pull/60 ACCUMULO-3509: Allow cleanup state to be kept to avoid blocking tserv… …er session sweep By enabling state ( true/false) from the cleanup method, the change will avoid blocking on a scan session being swept. if the session cleanup blocks because a ScanSession is still being read, we may block until the ScanBatch returns for that ScanSession. The change uses a simple semaphore ( purely because I like the word ) to attempt acquisition. If that fails, we return false from the cleanup and reintroduce that Session back into the queue to clean up. Added unit test that in the error condition will show the missing scan sessions ( which are missing due to the cleanup being blocked) You can merge this pull request into a Git repository by running: $ git pull https://github.com/phrocker/accumulo-1 master Alternatively you can review and apply these changes as the patch at: https://github.com/apache/accumulo/pull/60.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #60 commit bbd2257a001d654a87b433bb387ad9fce402dbb8 Author: phrocker Date: 2015-12-31T15:16:49Z ACCUMULO-3509: Allow cleanup state to be kept to avoid blocking tserver session sweep By enabling state ( true/false) from the cleanup method, the change will avoid blocking on a scan session being swept. if the session cleanup blocks because a ScanSession is still being read, we may block until the ScanBatch returns for that ScanSession. The change uses a simple semaphore ( purely because I like the word ) to attempt acquisition. If that fails, we return false from the cleanup and reintroduce that Session back into the queue to clean up. > 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.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)
[jira] [Commented] (ACCUMULO-3509) Scanner lock cause Tablet lock, hence preventing idle scans from being swept, hence blocking SimpleTimer thread
[ https://issues.apache.org/jira/browse/ACCUMULO-3509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15080690#comment-15080690 ] Josh Elser commented on ACCUMULO-3509: -- [~phrocker] is this relevant for 1.6.5 and 1.7.1 too? > 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.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)
[jira] [Commented] (ACCUMULO-3509) Scanner lock cause Tablet lock, hence preventing idle scans from being swept, hence blocking SimpleTimer thread
[ https://issues.apache.org/jira/browse/ACCUMULO-3509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15081049#comment-15081049 ] marco polo commented on ACCUMULO-3509: -- Yes, shall I decline PR and target 1.6.5 so it can be merged up appropriately? > 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)
[jira] [Commented] (ACCUMULO-3509) Scanner lock cause Tablet lock, hence preventing idle scans from being swept, hence blocking SimpleTimer thread
[ https://issues.apache.org/jira/browse/ACCUMULO-3509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15081142#comment-15081142 ] ASF GitHub Bot commented on ACCUMULO-3509: -- Github user phrocker commented on the pull request: https://github.com/apache/accumulo/pull/60#issuecomment-168673706 I'm going to target 1.6.5 so it can be merged up. > 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)
[jira] [Commented] (ACCUMULO-3509) Scanner lock cause Tablet lock, hence preventing idle scans from being swept, hence blocking SimpleTimer thread
[ https://issues.apache.org/jira/browse/ACCUMULO-3509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15081143#comment-15081143 ] ASF GitHub Bot commented on ACCUMULO-3509: -- Github user phrocker closed the pull request at: https://github.com/apache/accumulo/pull/60 > 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)
[jira] [Commented] (ACCUMULO-3509) Scanner lock cause Tablet lock, hence preventing idle scans from being swept, hence blocking SimpleTimer thread
[ https://issues.apache.org/jira/browse/ACCUMULO-3509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15081319#comment-15081319 ] ASF GitHub Bot commented on ACCUMULO-3509: -- GitHub user phrocker opened a pull request: https://github.com/apache/accumulo/pull/62 ACCUMULO-3509: Make cleanup stateful to minimize blocking By enabling state ( true/false) within the cleanup method, the change will avoid blocking on a scan session being swept. if the session cleanup blocks because a ScanSession is still being read, we may block until the ScanBatch returns for that ScanSession. The change uses a simple semaphore ( purely because I like the word ) to attempt acquisition. If that fails, we return false from the cleanup and reintroduce that Session back into the queue to clean up. You can merge this pull request into a Git repository by running: $ git pull https://github.com/phrocker/accumulo-1 1.6 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/accumulo/pull/62.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #62 commit 7918bd121e772738833a595ea3e83e5c76c6474c Author: phrocker Date: 2016-01-04T15:59:28Z ACCUMULO-3509: Make cleanup stateful to minimize blocking By enabling state ( true/false) within the cleanup method, the change will avoid blocking on a scan session being swept. if the session cleanup blocks because a ScanSession is still being read, we may block until the ScanBatch returns for that ScanSession. The change uses a simple semaphore ( purely because I like the word ) to attempt acquisition. If that fails, we return false from the cleanup and reintroduce that Session back into the queue to clean up. > 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)
[jira] [Commented] (ACCUMULO-3509) Scanner lock cause Tablet lock, hence preventing idle scans from being swept, hence blocking SimpleTimer thread
[ 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)
[jira] [Commented] (ACCUMULO-3509) Scanner lock cause Tablet lock, hence preventing idle scans from being swept, hence blocking SimpleTimer thread
[ 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)
[jira] [Commented] (ACCUMULO-3509) Scanner lock cause Tablet lock, hence preventing idle scans from being swept, hence blocking SimpleTimer thread
[ 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)
[jira] [Commented] (ACCUMULO-3509) Scanner lock cause Tablet lock, hence preventing idle scans from being swept, hence blocking SimpleTimer thread
[ https://issues.apache.org/jira/browse/ACCUMULO-3509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15081384#comment-15081384 ] 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_r48753512 --- 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 -- I made a typo when writing the patch from my other machine. I made the boolean volatile there but in talking with you I will move the scanClosed below the acquisition to avoid the issue entirely and ensure cache coherency. > 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)
[jira] [Commented] (ACCUMULO-3509) Scanner lock cause Tablet lock, hence preventing idle scans from being swept, hence blocking SimpleTimer thread
[ https://issues.apache.org/jira/browse/ACCUMULO-3509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15081392#comment-15081392 ] 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_r48753936 --- 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 -- The expense of fairness may not be a problem. I suspect the expense of fairness is an issue for semaphores that are frequently accessed by many threads, which is not the case here. > 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)
[jira] [Commented] (ACCUMULO-3509) Scanner lock cause Tablet lock, hence preventing idle scans from being swept, hence blocking SimpleTimer thread
[ https://issues.apache.org/jira/browse/ACCUMULO-3509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15081671#comment-15081671 ] 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_r48772476 --- Diff: core/src/main/java/org/apache/accumulo/core/conf/Property.java --- @@ -226,6 +226,7 @@ TSERV_MEM_MGMT("tserver.memory.manager", "org.apache.accumulo.server.tabletserver.LargestFirstMemoryManager", PropertyType.CLASSNAME, "An implementation of MemoryManger that accumulo will use."), TSERV_SESSION_MAXIDLE("tserver.session.idle.max", "1m", PropertyType.TIMEDURATION, "maximum idle time for a session"), + TSERV_UPDATE_SESSION_MAXIDLE("tserver.session.update.idle.max", "1m", PropertyType.TIMEDURATION, "maximum idle time for an update session"), --- End diff -- Could you make the new property description a complete sentence, please? > 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)
[jira] [Commented] (ACCUMULO-3509) Scanner lock cause Tablet lock, hence preventing idle scans from being swept, hence blocking SimpleTimer thread
[ 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 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)
[jira] [Commented] (ACCUMULO-3509) Scanner lock cause Tablet lock, hence preventing idle scans from being swept, hence blocking SimpleTimer thread
[ https://issues.apache.org/jira/browse/ACCUMULO-3509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15081706#comment-15081706 ] 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_r48775109 --- Diff: server/tserver/src/main/java/org/apache/accumulo/tserver/Tablet.java --- @@ -1761,33 +1763,41 @@ Scanner createScanner(Range range, int num, Set columns, Authorizations private ScanDataSource isolatedDataSource; private boolean sawException = false; private boolean scanClosed = false; +private Semaphore scannerSemaphore; --- End diff -- A javadoc comment describing why a semaphore is used would be nice when looking at this code in the future. > 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)
[jira] [Commented] (ACCUMULO-3509) Scanner lock cause Tablet lock, hence preventing idle scans from being swept, hence blocking SimpleTimer thread
[ https://issues.apache.org/jira/browse/ACCUMULO-3509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15081786#comment-15081786 ] 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_r48779554 --- Diff: test/src/test/java/org/apache/accumulo/test/functional/SessionBlockVerifyIT.java --- @@ -0,0 +1,181 @@ +/* + * Licensed to the Apache Software Foundation (ASF) under one or more + * contributor license agreements. See the NOTICE file distributed with + * this work for additional information regarding copyright ownership. + * The ASF licenses this file to You under the Apache License, Version 2.0 + * (the "License"); you may not use this file except in compliance with + * the License. You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, software + * distributed under the License is distributed on an "AS IS" BASIS, + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + * See the License for the specific language governing permissions and + * limitations under the License. + */ +package org.apache.accumulo.test.functional; + +import static java.nio.charset.StandardCharsets.UTF_8; +import static org.junit.Assert.assertEquals; +import static org.junit.Assert.assertTrue; + +import java.util.ArrayList; +import java.util.Iterator; +import java.util.List; +import java.util.Map; +import java.util.Map.Entry; +import java.util.concurrent.Callable; +import java.util.concurrent.ExecutorService; +import java.util.concurrent.Executors; +import java.util.concurrent.Future; + +import org.apache.accumulo.core.client.BatchWriter; +import org.apache.accumulo.core.client.BatchWriterConfig; +import org.apache.accumulo.core.client.Connector; +import org.apache.accumulo.core.client.IteratorSetting; +import org.apache.accumulo.core.client.Scanner; +import org.apache.accumulo.core.client.admin.ActiveScan; +import org.apache.accumulo.core.client.admin.InstanceOperations; +import org.apache.accumulo.core.conf.AccumuloConfiguration; +import org.apache.accumulo.core.conf.Property; +import org.apache.accumulo.core.data.Key; +import org.apache.accumulo.core.data.Mutation; +import org.apache.accumulo.core.data.Range; +import org.apache.accumulo.core.data.Value; +import org.apache.accumulo.core.security.Authorizations; +import org.apache.accumulo.harness.AccumuloClusterIT; +import org.apache.accumulo.minicluster.impl.MiniAccumuloConfigImpl; +import org.apache.hadoop.conf.Configuration; +import org.apache.hadoop.io.Text; +import org.junit.Before; +import org.junit.Test; +import org.slf4j.Logger; +import org.slf4j.LoggerFactory; + +/** + * Verify that we have resolved blocking issue by ensuring that we have not lost scan sessions which we know to currently be running + */ +public class SessionBlockVerifyIT extends AccumuloClusterIT { + private static final Logger log = LoggerFactory.getLogger(SessionBlockVerifyIT.class); + + @Override + public void configureMiniCluster(MiniAccumuloConfigImpl cfg, Configuration hadoopCoreSite) { +Map siteConfig = cfg.getSiteConfig(); +cfg.setNumTservers(1); +siteConfig.put(Property.TSERV_SESSION_MAXIDLE.getKey(), "1s"); +siteConfig.put(Property.TSERV_READ_AHEAD_MAXCONCURRENT.getKey(), "11"); +cfg.setSiteConfig(siteConfig); + } + + @Override + protected int defaultTimeoutSeconds() { +return 60; + } + + private String sessionIdle = null; + + @Before + public void reduceSessionIdle() throws Exception { + +InstanceOperations ops = getConnector().instanceOperations(); +sessionIdle = ops.getSystemConfiguration().get(Property.TSERV_SESSION_MAXIDLE.getKey()); +ops.setProperty(Property.TSERV_SESSION_MAXIDLE.getKey(), "1s"); +log.info("Waiting for existing session idle time to expire"); +Thread.sleep(AccumuloConfiguration.getTimeInMillis(sessionIdle)); +log.info("Finished waiting"); + } + + ExecutorService service = Executors.newFixedThreadPool(10); --- End diff -- Create this inside the test case? Or in a `@BeforeClass`? Something that we can make sure it is cleaned up after the test completes. > Scanner lock cause Tablet lock, hence preventing idle scans from being swept, > hence blocking SimpleTimer thread > > > Key:
[jira] [Commented] (ACCUMULO-3509) Scanner lock cause Tablet lock, hence preventing idle scans from being swept, hence blocking SimpleTimer thread
[ https://issues.apache.org/jira/browse/ACCUMULO-3509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15081788#comment-15081788 ] 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_r48779729 --- Diff: test/src/test/java/org/apache/accumulo/test/functional/SessionBlockVerifyIT.java --- @@ -0,0 +1,181 @@ +/* + * Licensed to the Apache Software Foundation (ASF) under one or more + * contributor license agreements. See the NOTICE file distributed with + * this work for additional information regarding copyright ownership. + * The ASF licenses this file to You under the Apache License, Version 2.0 + * (the "License"); you may not use this file except in compliance with + * the License. You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, software + * distributed under the License is distributed on an "AS IS" BASIS, + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + * See the License for the specific language governing permissions and + * limitations under the License. + */ +package org.apache.accumulo.test.functional; + +import static java.nio.charset.StandardCharsets.UTF_8; +import static org.junit.Assert.assertEquals; +import static org.junit.Assert.assertTrue; + +import java.util.ArrayList; +import java.util.Iterator; +import java.util.List; +import java.util.Map; +import java.util.Map.Entry; +import java.util.concurrent.Callable; +import java.util.concurrent.ExecutorService; +import java.util.concurrent.Executors; +import java.util.concurrent.Future; + +import org.apache.accumulo.core.client.BatchWriter; +import org.apache.accumulo.core.client.BatchWriterConfig; +import org.apache.accumulo.core.client.Connector; +import org.apache.accumulo.core.client.IteratorSetting; +import org.apache.accumulo.core.client.Scanner; +import org.apache.accumulo.core.client.admin.ActiveScan; +import org.apache.accumulo.core.client.admin.InstanceOperations; +import org.apache.accumulo.core.conf.AccumuloConfiguration; +import org.apache.accumulo.core.conf.Property; +import org.apache.accumulo.core.data.Key; +import org.apache.accumulo.core.data.Mutation; +import org.apache.accumulo.core.data.Range; +import org.apache.accumulo.core.data.Value; +import org.apache.accumulo.core.security.Authorizations; +import org.apache.accumulo.harness.AccumuloClusterIT; +import org.apache.accumulo.minicluster.impl.MiniAccumuloConfigImpl; +import org.apache.hadoop.conf.Configuration; +import org.apache.hadoop.io.Text; +import org.junit.Before; +import org.junit.Test; +import org.slf4j.Logger; +import org.slf4j.LoggerFactory; + +/** + * Verify that we have resolved blocking issue by ensuring that we have not lost scan sessions which we know to currently be running + */ +public class SessionBlockVerifyIT extends AccumuloClusterIT { + private static final Logger log = LoggerFactory.getLogger(SessionBlockVerifyIT.class); + + @Override + public void configureMiniCluster(MiniAccumuloConfigImpl cfg, Configuration hadoopCoreSite) { +Map siteConfig = cfg.getSiteConfig(); +cfg.setNumTservers(1); +siteConfig.put(Property.TSERV_SESSION_MAXIDLE.getKey(), "1s"); +siteConfig.put(Property.TSERV_READ_AHEAD_MAXCONCURRENT.getKey(), "11"); +cfg.setSiteConfig(siteConfig); + } + + @Override + protected int defaultTimeoutSeconds() { +return 60; + } + + private String sessionIdle = null; + + @Before + public void reduceSessionIdle() throws Exception { + +InstanceOperations ops = getConnector().instanceOperations(); +sessionIdle = ops.getSystemConfiguration().get(Property.TSERV_SESSION_MAXIDLE.getKey()); +ops.setProperty(Property.TSERV_SESSION_MAXIDLE.getKey(), "1s"); +log.info("Waiting for existing session idle time to expire"); +Thread.sleep(AccumuloConfiguration.getTimeInMillis(sessionIdle)); +log.info("Finished waiting"); + } + + ExecutorService service = Executors.newFixedThreadPool(10); + + @Test + public void run() throws Exception { +Connector c = getConnector(); +String tableName = getUniqueNames(1)[0]; +c.tableOperations().create(tableName); + +BatchWriter bw = c.createBatchWriter(tableName, new BatchWriterConfig()); + +for (int i = 0; i < 1000; i++) { + Mutation m = new Mutation(new Text(String.format("%08d", i))); +
[jira] [Commented] (ACCUMULO-3509) Scanner lock cause Tablet lock, hence preventing idle scans from being swept, hence blocking SimpleTimer thread
[ https://issues.apache.org/jira/browse/ACCUMULO-3509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15081792#comment-15081792 ] 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_r48779936 --- Diff: test/src/test/java/org/apache/accumulo/test/functional/SessionBlockVerifyIT.java --- @@ -0,0 +1,181 @@ +/* + * Licensed to the Apache Software Foundation (ASF) under one or more + * contributor license agreements. See the NOTICE file distributed with + * this work for additional information regarding copyright ownership. + * The ASF licenses this file to You under the Apache License, Version 2.0 + * (the "License"); you may not use this file except in compliance with + * the License. You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, software + * distributed under the License is distributed on an "AS IS" BASIS, + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + * See the License for the specific language governing permissions and + * limitations under the License. + */ +package org.apache.accumulo.test.functional; + +import static java.nio.charset.StandardCharsets.UTF_8; +import static org.junit.Assert.assertEquals; +import static org.junit.Assert.assertTrue; + +import java.util.ArrayList; +import java.util.Iterator; +import java.util.List; +import java.util.Map; +import java.util.Map.Entry; +import java.util.concurrent.Callable; +import java.util.concurrent.ExecutorService; +import java.util.concurrent.Executors; +import java.util.concurrent.Future; + +import org.apache.accumulo.core.client.BatchWriter; +import org.apache.accumulo.core.client.BatchWriterConfig; +import org.apache.accumulo.core.client.Connector; +import org.apache.accumulo.core.client.IteratorSetting; +import org.apache.accumulo.core.client.Scanner; +import org.apache.accumulo.core.client.admin.ActiveScan; +import org.apache.accumulo.core.client.admin.InstanceOperations; +import org.apache.accumulo.core.conf.AccumuloConfiguration; +import org.apache.accumulo.core.conf.Property; +import org.apache.accumulo.core.data.Key; +import org.apache.accumulo.core.data.Mutation; +import org.apache.accumulo.core.data.Range; +import org.apache.accumulo.core.data.Value; +import org.apache.accumulo.core.security.Authorizations; +import org.apache.accumulo.harness.AccumuloClusterIT; +import org.apache.accumulo.minicluster.impl.MiniAccumuloConfigImpl; +import org.apache.hadoop.conf.Configuration; +import org.apache.hadoop.io.Text; +import org.junit.Before; +import org.junit.Test; +import org.slf4j.Logger; +import org.slf4j.LoggerFactory; + +/** + * Verify that we have resolved blocking issue by ensuring that we have not lost scan sessions which we know to currently be running + */ +public class SessionBlockVerifyIT extends AccumuloClusterIT { + private static final Logger log = LoggerFactory.getLogger(SessionBlockVerifyIT.class); + + @Override + public void configureMiniCluster(MiniAccumuloConfigImpl cfg, Configuration hadoopCoreSite) { +Map siteConfig = cfg.getSiteConfig(); +cfg.setNumTservers(1); +siteConfig.put(Property.TSERV_SESSION_MAXIDLE.getKey(), "1s"); +siteConfig.put(Property.TSERV_READ_AHEAD_MAXCONCURRENT.getKey(), "11"); +cfg.setSiteConfig(siteConfig); + } + + @Override + protected int defaultTimeoutSeconds() { +return 60; + } + + private String sessionIdle = null; + + @Before + public void reduceSessionIdle() throws Exception { + +InstanceOperations ops = getConnector().instanceOperations(); +sessionIdle = ops.getSystemConfiguration().get(Property.TSERV_SESSION_MAXIDLE.getKey()); +ops.setProperty(Property.TSERV_SESSION_MAXIDLE.getKey(), "1s"); +log.info("Waiting for existing session idle time to expire"); +Thread.sleep(AccumuloConfiguration.getTimeInMillis(sessionIdle)); +log.info("Finished waiting"); + } + + ExecutorService service = Executors.newFixedThreadPool(10); + + @Test + public void run() throws Exception { +Connector c = getConnector(); +String tableName = getUniqueNames(1)[0]; +c.tableOperations().create(tableName); + +BatchWriter bw = c.createBatchWriter(tableName, new BatchWriterConfig()); + +for (int i = 0; i < 1000; i++) { + Mutation m = new Mutation(new Text(String.format("%08d", i))); +
[jira] [Commented] (ACCUMULO-3509) Scanner lock cause Tablet lock, hence preventing idle scans from being swept, hence blocking SimpleTimer thread
[ https://issues.apache.org/jira/browse/ACCUMULO-3509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15081794#comment-15081794 ] 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_r48780215 --- Diff: test/src/test/java/org/apache/accumulo/test/functional/SessionBlockVerifyIT.java --- @@ -0,0 +1,181 @@ +/* + * Licensed to the Apache Software Foundation (ASF) under one or more + * contributor license agreements. See the NOTICE file distributed with + * this work for additional information regarding copyright ownership. + * The ASF licenses this file to You under the Apache License, Version 2.0 + * (the "License"); you may not use this file except in compliance with + * the License. You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, software + * distributed under the License is distributed on an "AS IS" BASIS, + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + * See the License for the specific language governing permissions and + * limitations under the License. + */ +package org.apache.accumulo.test.functional; + +import static java.nio.charset.StandardCharsets.UTF_8; +import static org.junit.Assert.assertEquals; +import static org.junit.Assert.assertTrue; + +import java.util.ArrayList; +import java.util.Iterator; +import java.util.List; +import java.util.Map; +import java.util.Map.Entry; +import java.util.concurrent.Callable; +import java.util.concurrent.ExecutorService; +import java.util.concurrent.Executors; +import java.util.concurrent.Future; + +import org.apache.accumulo.core.client.BatchWriter; +import org.apache.accumulo.core.client.BatchWriterConfig; +import org.apache.accumulo.core.client.Connector; +import org.apache.accumulo.core.client.IteratorSetting; +import org.apache.accumulo.core.client.Scanner; +import org.apache.accumulo.core.client.admin.ActiveScan; +import org.apache.accumulo.core.client.admin.InstanceOperations; +import org.apache.accumulo.core.conf.AccumuloConfiguration; +import org.apache.accumulo.core.conf.Property; +import org.apache.accumulo.core.data.Key; +import org.apache.accumulo.core.data.Mutation; +import org.apache.accumulo.core.data.Range; +import org.apache.accumulo.core.data.Value; +import org.apache.accumulo.core.security.Authorizations; +import org.apache.accumulo.harness.AccumuloClusterIT; +import org.apache.accumulo.minicluster.impl.MiniAccumuloConfigImpl; +import org.apache.hadoop.conf.Configuration; +import org.apache.hadoop.io.Text; +import org.junit.Before; +import org.junit.Test; +import org.slf4j.Logger; +import org.slf4j.LoggerFactory; + +/** + * Verify that we have resolved blocking issue by ensuring that we have not lost scan sessions which we know to currently be running + */ +public class SessionBlockVerifyIT extends AccumuloClusterIT { + private static final Logger log = LoggerFactory.getLogger(SessionBlockVerifyIT.class); + + @Override + public void configureMiniCluster(MiniAccumuloConfigImpl cfg, Configuration hadoopCoreSite) { +Map siteConfig = cfg.getSiteConfig(); +cfg.setNumTservers(1); +siteConfig.put(Property.TSERV_SESSION_MAXIDLE.getKey(), "1s"); +siteConfig.put(Property.TSERV_READ_AHEAD_MAXCONCURRENT.getKey(), "11"); +cfg.setSiteConfig(siteConfig); + } + + @Override + protected int defaultTimeoutSeconds() { +return 60; + } + + private String sessionIdle = null; + + @Before + public void reduceSessionIdle() throws Exception { + +InstanceOperations ops = getConnector().instanceOperations(); +sessionIdle = ops.getSystemConfiguration().get(Property.TSERV_SESSION_MAXIDLE.getKey()); +ops.setProperty(Property.TSERV_SESSION_MAXIDLE.getKey(), "1s"); +log.info("Waiting for existing session idle time to expire"); +Thread.sleep(AccumuloConfiguration.getTimeInMillis(sessionIdle)); +log.info("Finished waiting"); + } + + ExecutorService service = Executors.newFixedThreadPool(10); + + @Test + public void run() throws Exception { +Connector c = getConnector(); +String tableName = getUniqueNames(1)[0]; +c.tableOperations().create(tableName); + +BatchWriter bw = c.createBatchWriter(tableName, new BatchWriterConfig()); + +for (int i = 0; i < 1000; i++) { + Mutation m = new Mutation(new Text(String.format("%08d", i))); +
[jira] [Commented] (ACCUMULO-3509) Scanner lock cause Tablet lock, hence preventing idle scans from being swept, hence blocking SimpleTimer thread
[ https://issues.apache.org/jira/browse/ACCUMULO-3509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15081796#comment-15081796 ] 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_r48780266 --- Diff: test/src/test/java/org/apache/accumulo/test/functional/SessionBlockVerifyIT.java --- @@ -0,0 +1,181 @@ +/* + * Licensed to the Apache Software Foundation (ASF) under one or more + * contributor license agreements. See the NOTICE file distributed with + * this work for additional information regarding copyright ownership. + * The ASF licenses this file to You under the Apache License, Version 2.0 + * (the "License"); you may not use this file except in compliance with + * the License. You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, software + * distributed under the License is distributed on an "AS IS" BASIS, + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + * See the License for the specific language governing permissions and + * limitations under the License. + */ +package org.apache.accumulo.test.functional; + +import static java.nio.charset.StandardCharsets.UTF_8; +import static org.junit.Assert.assertEquals; +import static org.junit.Assert.assertTrue; + +import java.util.ArrayList; +import java.util.Iterator; +import java.util.List; +import java.util.Map; +import java.util.Map.Entry; +import java.util.concurrent.Callable; +import java.util.concurrent.ExecutorService; +import java.util.concurrent.Executors; +import java.util.concurrent.Future; + +import org.apache.accumulo.core.client.BatchWriter; +import org.apache.accumulo.core.client.BatchWriterConfig; +import org.apache.accumulo.core.client.Connector; +import org.apache.accumulo.core.client.IteratorSetting; +import org.apache.accumulo.core.client.Scanner; +import org.apache.accumulo.core.client.admin.ActiveScan; +import org.apache.accumulo.core.client.admin.InstanceOperations; +import org.apache.accumulo.core.conf.AccumuloConfiguration; +import org.apache.accumulo.core.conf.Property; +import org.apache.accumulo.core.data.Key; +import org.apache.accumulo.core.data.Mutation; +import org.apache.accumulo.core.data.Range; +import org.apache.accumulo.core.data.Value; +import org.apache.accumulo.core.security.Authorizations; +import org.apache.accumulo.harness.AccumuloClusterIT; +import org.apache.accumulo.minicluster.impl.MiniAccumuloConfigImpl; +import org.apache.hadoop.conf.Configuration; +import org.apache.hadoop.io.Text; +import org.junit.Before; +import org.junit.Test; +import org.slf4j.Logger; +import org.slf4j.LoggerFactory; + +/** + * Verify that we have resolved blocking issue by ensuring that we have not lost scan sessions which we know to currently be running + */ +public class SessionBlockVerifyIT extends AccumuloClusterIT { + private static final Logger log = LoggerFactory.getLogger(SessionBlockVerifyIT.class); + + @Override + public void configureMiniCluster(MiniAccumuloConfigImpl cfg, Configuration hadoopCoreSite) { +Map siteConfig = cfg.getSiteConfig(); +cfg.setNumTservers(1); +siteConfig.put(Property.TSERV_SESSION_MAXIDLE.getKey(), "1s"); +siteConfig.put(Property.TSERV_READ_AHEAD_MAXCONCURRENT.getKey(), "11"); +cfg.setSiteConfig(siteConfig); + } + + @Override + protected int defaultTimeoutSeconds() { +return 60; + } + + private String sessionIdle = null; + + @Before + public void reduceSessionIdle() throws Exception { + +InstanceOperations ops = getConnector().instanceOperations(); +sessionIdle = ops.getSystemConfiguration().get(Property.TSERV_SESSION_MAXIDLE.getKey()); +ops.setProperty(Property.TSERV_SESSION_MAXIDLE.getKey(), "1s"); +log.info("Waiting for existing session idle time to expire"); +Thread.sleep(AccumuloConfiguration.getTimeInMillis(sessionIdle)); +log.info("Finished waiting"); + } + + ExecutorService service = Executors.newFixedThreadPool(10); + + @Test + public void run() throws Exception { +Connector c = getConnector(); +String tableName = getUniqueNames(1)[0]; +c.tableOperations().create(tableName); + +BatchWriter bw = c.createBatchWriter(tableName, new BatchWriterConfig()); + +for (int i = 0; i < 1000; i++) { + Mutation m = new Mutation(new Text(String.format("%08d", i))); +
[jira] [Commented] (ACCUMULO-3509) Scanner lock cause Tablet lock, hence preventing idle scans from being swept, hence blocking SimpleTimer thread
[ https://issues.apache.org/jira/browse/ACCUMULO-3509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15081798#comment-15081798 ] ASF GitHub Bot commented on ACCUMULO-3509: -- Github user joshelser commented on the pull request: https://github.com/apache/accumulo/pull/62#issuecomment-168807086 Looks pretty good, @phrocker. I left you some nit-picky suggestions which would improve the changes a bit and hopefully make sure your included integration test runs on any hardware (yay, included integration test!!). > 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)
[jira] [Commented] (ACCUMULO-3509) Scanner lock cause Tablet lock, hence preventing idle scans from being swept, hence blocking SimpleTimer thread
[ https://issues.apache.org/jira/browse/ACCUMULO-3509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15083065#comment-15083065 ] ASF GitHub Bot commented on ACCUMULO-3509: -- Github user phrocker commented on a diff in the pull request: https://github.com/apache/accumulo/pull/62#discussion_r48845580 --- Diff: test/src/test/java/org/apache/accumulo/test/functional/SessionBlockVerifyIT.java --- @@ -0,0 +1,181 @@ +/* + * Licensed to the Apache Software Foundation (ASF) under one or more + * contributor license agreements. See the NOTICE file distributed with + * this work for additional information regarding copyright ownership. + * The ASF licenses this file to You under the Apache License, Version 2.0 + * (the "License"); you may not use this file except in compliance with + * the License. You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, software + * distributed under the License is distributed on an "AS IS" BASIS, + * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. + * See the License for the specific language governing permissions and + * limitations under the License. + */ +package org.apache.accumulo.test.functional; + +import static java.nio.charset.StandardCharsets.UTF_8; +import static org.junit.Assert.assertEquals; +import static org.junit.Assert.assertTrue; + +import java.util.ArrayList; +import java.util.Iterator; +import java.util.List; +import java.util.Map; +import java.util.Map.Entry; +import java.util.concurrent.Callable; +import java.util.concurrent.ExecutorService; +import java.util.concurrent.Executors; +import java.util.concurrent.Future; + +import org.apache.accumulo.core.client.BatchWriter; +import org.apache.accumulo.core.client.BatchWriterConfig; +import org.apache.accumulo.core.client.Connector; +import org.apache.accumulo.core.client.IteratorSetting; +import org.apache.accumulo.core.client.Scanner; +import org.apache.accumulo.core.client.admin.ActiveScan; +import org.apache.accumulo.core.client.admin.InstanceOperations; +import org.apache.accumulo.core.conf.AccumuloConfiguration; +import org.apache.accumulo.core.conf.Property; +import org.apache.accumulo.core.data.Key; +import org.apache.accumulo.core.data.Mutation; +import org.apache.accumulo.core.data.Range; +import org.apache.accumulo.core.data.Value; +import org.apache.accumulo.core.security.Authorizations; +import org.apache.accumulo.harness.AccumuloClusterIT; +import org.apache.accumulo.minicluster.impl.MiniAccumuloConfigImpl; +import org.apache.hadoop.conf.Configuration; +import org.apache.hadoop.io.Text; +import org.junit.Before; +import org.junit.Test; +import org.slf4j.Logger; +import org.slf4j.LoggerFactory; + +/** + * Verify that we have resolved blocking issue by ensuring that we have not lost scan sessions which we know to currently be running + */ +public class SessionBlockVerifyIT extends AccumuloClusterIT { + private static final Logger log = LoggerFactory.getLogger(SessionBlockVerifyIT.class); + + @Override + public void configureMiniCluster(MiniAccumuloConfigImpl cfg, Configuration hadoopCoreSite) { +Map siteConfig = cfg.getSiteConfig(); +cfg.setNumTservers(1); +siteConfig.put(Property.TSERV_SESSION_MAXIDLE.getKey(), "1s"); +siteConfig.put(Property.TSERV_READ_AHEAD_MAXCONCURRENT.getKey(), "11"); +cfg.setSiteConfig(siteConfig); + } + + @Override + protected int defaultTimeoutSeconds() { +return 60; + } + + private String sessionIdle = null; + + @Before + public void reduceSessionIdle() throws Exception { + +InstanceOperations ops = getConnector().instanceOperations(); +sessionIdle = ops.getSystemConfiguration().get(Property.TSERV_SESSION_MAXIDLE.getKey()); +ops.setProperty(Property.TSERV_SESSION_MAXIDLE.getKey(), "1s"); +log.info("Waiting for existing session idle time to expire"); +Thread.sleep(AccumuloConfiguration.getTimeInMillis(sessionIdle)); +log.info("Finished waiting"); + } + + ExecutorService service = Executors.newFixedThreadPool(10); + + @Test + public void run() throws Exception { +Connector c = getConnector(); +String tableName = getUniqueNames(1)[0]; +c.tableOperations().create(tableName); + +BatchWriter bw = c.createBatchWriter(tableName, new BatchWriterConfig()); + +for (int i = 0; i < 1000; i++) { + Mutation m = new Mutation(new Text(String.format("%08d", i))); +
[jira] [Commented] (ACCUMULO-3509) Scanner lock cause Tablet lock, hence preventing idle scans from being swept, hence blocking SimpleTimer thread
[ https://issues.apache.org/jira/browse/ACCUMULO-3509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15083224#comment-15083224 ] ASF GitHub Bot commented on ACCUMULO-3509: -- Github user joshelser commented on the pull request: https://github.com/apache/accumulo/pull/62#issuecomment-169034981 Thanks, @phrocker. Future-Josh thanks you too (hopefully your improvements will save me another round of "make our ITs stable". > 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)
[jira] [Commented] (ACCUMULO-3509) Scanner lock cause Tablet lock, hence preventing idle scans from being swept, hence blocking SimpleTimer thread
[ https://issues.apache.org/jira/browse/ACCUMULO-3509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15092371#comment-15092371 ] Josh Elser commented on ACCUMULO-3509: -- Let's try to trigger Yetus: https://github.com/apache/accumulo/pull/62.patch > 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)
[jira] [Commented] (ACCUMULO-3509) Scanner lock cause Tablet lock, hence preventing idle scans from being swept, hence blocking SimpleTimer thread
[ https://issues.apache.org/jira/browse/ACCUMULO-3509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15092461#comment-15092461 ] Hadoop QA commented on ACCUMULO-3509: - | (/) *{color:green}+1 overall{color}* | \\ \\ || Vote || Subsystem || Runtime || Comment || | {color:green}+1{color} | {color:green} @author {color} | {color:green} 0m 0s {color} | {color:green} The patch does not contain any @author tags. {color} | | {color:green}+1{color} | {color:green} test4tests {color} | {color:green} 0m 0s {color} | {color:green} The patch appears to include 2 new or modified test files. {color} | | {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 2m 34s {color} | {color:green} 1.6 passed {color} | | {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 35s {color} | {color:green} 1.6 passed with JDK v1.8.0 {color} | | {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 3s {color} | {color:green} 1.6 passed with JDK v1.7.0_79 {color} | | {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m 12s {color} | {color:green} 1.6 passed {color} | | {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m 43s {color} | {color:green} 1.6 passed {color} | | {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 3m 23s {color} | {color:green} 1.6 passed {color} | | {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 0m 58s {color} | {color:green} 1.6 passed with JDK v1.8.0 {color} | | {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 8s {color} | {color:green} 1.6 passed with JDK v1.7.0_79 {color} | | {color:green}+1{color} | {color:green} mvninstall {color} | {color:green} 1m 12s {color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 26s {color} | {color:green} the patch passed with JDK v1.8.0 {color} | | {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m 26s {color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} compile {color} | {color:green} 1m 3s {color} | {color:green} the patch passed with JDK v1.7.0_79 {color} | | {color:green}+1{color} | {color:green} javac {color} | {color:green} 1m 3s {color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} checkstyle {color} | {color:green} 1m 10s {color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} mvneclipse {color} | {color:green} 0m 39s {color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} whitespace {color} | {color:green} 0m 0s {color} | {color:green} Patch has no whitespace issues. {color} | | {color:green}+1{color} | {color:green} findbugs {color} | {color:green} 3m 55s {color} | {color:green} the patch passed {color} | | {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 2s {color} | {color:green} the patch passed with JDK v1.8.0 {color} | | {color:green}+1{color} | {color:green} javadoc {color} | {color:green} 1m 6s {color} | {color:green} the patch passed with JDK v1.7.0_79 {color} | | {color:green}+1{color} | {color:green} unit {color} | {color:green} 8m 0s {color} | {color:green} root in the patch passed with JDK v1.8.0. {color} | | {color:green}+1{color} | {color:green} unit {color} | {color:green} 8m 11s {color} | {color:green} root in the patch passed with JDK v1.7.0_79. {color} | | {color:green}+1{color} | {color:green} asflicense {color} | {color:green} 0m 16s {color} | {color:green} Patch does not generate ASF License warnings. {color} | | {color:black}{color} | {color:black} {color} | {color:black} 41m 40s {color} | {color:black} {color} | \\ \\ || Subsystem || Report/Notes || | JIRA Issue | ACCUMULO-3509 | | GITHUB PR | https://github.com/apache/accumulo/pull/62 | | Optional Tests | asflicense javac javadoc unit findbugs checkstyle compile | | uname | Linux asf904.gq1.ygridcore.net 3.13.0-36-lowlatency #63-Ubuntu SMP PREEMPT Wed Sep 3 21:56:12 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux | | Build tool | maven | | Personality | /home/jenkins/jenkins-slave/workspace/PreCommit-ACCUMULO-Build/test_framework/apache-yetus-6ce890b/precommit/personality/accumulo.sh | | git revision | 1.6 / 8669215 | | Default Java | 1.7.0_79 | | Multi-JDK versions | /home/jenkins/tools/java/jdk1.8.0:1.8.0 /usr/local/jenkins/java/jdk1.7.0_79:1.7.0_79 | | findbugs | v2.0.3 | | JDK v1.7.0_79 Test Results | https://builds.apache.org/job/PreCommit-ACCUMULO-Build/14/testReport/ | | modules | C: core server/tserver test U: . | | Max memory used | 96MB | | Powered by | Apache Yetus 0.2.0-SNAPSHOT http://yetus.apache.org | | Console output | https://builds.apache.org/job/PreCommit-ACCUMULO-Build/14/console | | Console output | https://builds.
[jira] [Commented] (ACCUMULO-3509) Scanner lock cause Tablet lock, hence preventing idle scans from being swept, hence blocking SimpleTimer thread
[ https://issues.apache.org/jira/browse/ACCUMULO-3509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15092526#comment-15092526 ] Josh Elser commented on ACCUMULO-3509: -- I will run this through some ITs and then merge today. Thanks in advance, [~phrocker]! > 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 > > Attachments: ACCUMULO-3509-1.6.patch > > > 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)
[jira] [Commented] (ACCUMULO-3509) Scanner lock cause Tablet lock, hence preventing idle scans from being swept, hence blocking SimpleTimer thread
[ https://issues.apache.org/jira/browse/ACCUMULO-3509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15093313#comment-15093313 ] ASF GitHub Bot commented on ACCUMULO-3509: -- Github user asfgit closed the pull request at: https://github.com/apache/accumulo/pull/62 > 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 > > Attachments: ACCUMULO-3509-1.6.patch > > Time Spent: 0.5h > Remaining Estimate: 0h > > 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)
[jira] [Commented] (ACCUMULO-3509) Scanner lock cause Tablet lock, hence preventing idle scans from being swept, hence blocking SimpleTimer thread
[ https://issues.apache.org/jira/browse/ACCUMULO-3509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15096904#comment-15096904 ] Josh Elser commented on ACCUMULO-3509: -- Building 1.7, I saw that there was a compiler warning because we were returning a value inside of a finally. This could have masked an exception when closing the scan task (inside ScanSession). Cleaned this up in 8c6866efbb40aa1732b79f99c92458f3e672d14a > 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 > > Attachments: ACCUMULO-3509-1.6.patch > > Time Spent: 1h > Remaining Estimate: 0h > > 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)