[jira] [Commented] (ACCUMULO-3509) Scanner lock cause Tablet lock, hence preventing idle scans from being swept, hence blocking SimpleTimer thread

[Josh Elser (JIRA)]

[ 
https://issues.apache.org/jira/browse/ACCUMULO-3509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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)

[jira] [Commented] (ACCUMULO-3509) Scanner lock cause Tablet lock, hence preventing idle scans from being swept, hence blocking SimpleTimer thread

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/ACCUMULO-3509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[Hadoop QA (JIRA)]

[ 
https://issues.apache.org/jira/browse/ACCUMULO-3509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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 | 

[jira] [Commented] (ACCUMULO-3509) Scanner lock cause Tablet lock, hence preventing idle scans from being swept, hence blocking SimpleTimer thread

[Josh Elser (JIRA)]

[ 
https://issues.apache.org/jira/browse/ACCUMULO-3509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[Josh Elser (JIRA)]

[ 
https://issues.apache.org/jira/browse/ACCUMULO-3509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/ACCUMULO-3509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/ACCUMULO-3509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/ACCUMULO-3509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/ACCUMULO-3509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/ACCUMULO-3509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/ACCUMULO-3509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/ACCUMULO-3509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/ACCUMULO-3509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/ACCUMULO-3509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/ACCUMULO-3509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[marco polo (JIRA)]

[ 
https://issues.apache.org/jira/browse/ACCUMULO-3509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/ACCUMULO-3509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/ACCUMULO-3509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/ACCUMULO-3509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/ACCUMULO-3509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/ACCUMULO-3509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/ACCUMULO-3509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/ACCUMULO-3509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/ACCUMULO-3509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[Josh Elser (JIRA)]

[ 
https://issues.apache.org/jira/browse/ACCUMULO-3509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/ACCUMULO-3509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[Christopher Tubbs (JIRA)]

[ 
https://issues.apache.org/jira/browse/ACCUMULO-3509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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

[John Vines (JIRA)]

[ 
https://issues.apache.org/jira/browse/ACCUMULO-3509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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)