[GitHub] keith-turner commented on a change in pull request #402: ACCUMULO-4615: Updated get status for thread safety and with a per-task timeout

[GitBox]

keith-turner commented on a change in pull request #402: ACCUMULO-4615: Updated 
get status for thread safety and with a per-task timeout
URL: https://github.com/apache/accumulo/pull/402#discussion_r175576157
 
 

 ##
 File path: 
server/master/src/main/java/org/apache/accumulo/master/TimeoutTaskExecutor.java
 ##
 @@ -0,0 +1,198 @@
+/*
+ * 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.master;
+
+import java.util.ArrayList;
+import java.util.List;
+import java.util.Objects;
+import java.util.concurrent.Callable;
+import java.util.concurrent.ExecutorService;
+import java.util.concurrent.Future;
+import java.util.concurrent.TimeUnit;
+import java.util.concurrent.TimeoutException;
+
+import org.slf4j.Logger;
+import org.slf4j.LoggerFactory;
+
+import com.google.common.base.Preconditions;
+
+/**
+ * Runs one or more tasks with a timeout per task (instead of a timeout for 
the entire pool). Uses callbacks to invoke functions on successful, timed out, 
or
+ * tasks that error.
+ *
+ * @param 
+ *  The return type for the corresponding Callable.
+ * @param 
+ *  The type of Callable submitted to this executor.
+ */
+public class TimeoutTaskExecutor implements 
AutoCloseable {
+
+  private final static Logger log = 
LoggerFactory.getLogger(TimeoutTaskExecutor.class);
+
+  private final long timeout;
+  private final ExecutorService executorService;
+  private final List wrappedTasks;
+
+  private SuccessCallback successCallback;
+  private ExceptionCallback exceptionCallback;
+  private TimeoutCallback timeoutCallback;
+
+  /**
+   * Constructs a new TimeoutTaskExecutor using the given executor to schedule 
tasks with a max timeout. Takes an expected number of Callables to initialize 
the
+   * underlying task collection more appropriately.
+   *
+   * @param executorService
+   *  The executor to schedule tasks with.
+   * @param timeout
+   *  The timeout for each task.
+   * @param expectedNumCallables
+   *  The expected number of callables you will schedule (for sizing 
optimization).
+   */
+  public TimeoutTaskExecutor(ExecutorService executorService, long timeout, 
int expectedNumCallables) {
+this.executorService = executorService;
+this.timeout = timeout;
+this.wrappedTasks = new ArrayList<>(expectedNumCallables);
+  }
+
+  /**
+   * Submits a new task to the executor.
+   *
+   * @param callable
+   *  Task to run
+   */
+  public void submit(C callable) {
+WrappedTask wt = new WrappedTask(callable, 
executorService.submit(callable));
+wrappedTasks.add(wt);
+  }
+
+  /**
+   * Registers the callback to use on successful tasks.
+   *
+   * @param successCallback
+   *  The callback function to invoke on success.
+   * @throws NullPointerException
+   *   when a null successCallback is passed in
+   */
+  public void onSuccess(SuccessCallback successCallback) {
+this.successCallback = Objects.requireNonNull(successCallback, "Must 
provide a non-null successCallback.");
+  }
+
+  /**
+   * Registers the callback to use on tasks that throw exceptions.
+   *
+   * @param exceptionCallback
+   *  The callback function to invoke on exceptions.
+   * @throws NullPointerException
+   *   when a null exceptionCallback is passed in
+   */
+  public void onException(ExceptionCallback exceptionCallback) {
+this.exceptionCallback = Objects.requireNonNull(exceptionCallback, "Must 
provide a non-null exceptionCallback.");
+  }
+
+  /**
+   * Registers the callback to use on tasks that time out.
+   *
+   * @param timeoutCallback
+   *  The callback function to invoke on timeouts.
+   * @throws NullPointerException
+   *   when a null timeoutCallback is passed in
+   */
+  public void onTimeout(TimeoutCallback timeoutCallback) {
+this.timeoutCallback = Objects.requireNonNull(timeoutCallback, "Must 
provide a non-null timeoutCallback.");
+  }
+
+  /**
+   * Completes all the current tasks by dispatching to the appropriated 
callback.
+   *
+   * @throws IllegalStateException
+   *   If all of the callbacks were not registered before calling this 
method.
+   * 

[GitHub] keith-turner commented on a change in pull request #402: ACCUMULO-4615: Updated get status for thread safety and with a per-task timeout

[GitBox]

keith-turner commented on a change in pull request #402: ACCUMULO-4615: Updated 
get status for thread safety and with a per-task timeout
URL: https://github.com/apache/accumulo/pull/402#discussion_r175585658
 
 

 ##
 File path: 
server/master/src/test/java/org/apache/accumulo/master/TimeoutTaskExecutorTest.java
 ##
 @@ -0,0 +1,134 @@
+/*
+ * 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.master;
+
+import static org.hamcrest.core.Is.is;
+import static org.junit.Assert.assertThat;
+import static org.junit.Assert.fail;
+
+import java.util.ArrayList;
+import java.util.Collection;
+import java.util.concurrent.Callable;
+import java.util.concurrent.Executors;
+
+import org.apache.accumulo.master.TimeoutTaskExecutor.SuccessCallback;
+import org.apache.accumulo.master.TimeoutTaskExecutor.TimeoutCallback;
+import org.junit.After;
+import org.junit.Before;
+import org.junit.Test;
+
+import com.google.common.collect.Iterables;
+
+public class TimeoutTaskExecutorTest {
+
+  private TimeoutTaskExecutor executor;
+  private long timeout = 100;
+
+  private Collection results;
+  private Collection timeouts;
+
+  @Before
+  public void setup() {
+int numThreads = 2;
+executor = new 
TimeoutTaskExecutor<>(Executors.newFixedThreadPool(numThreads), timeout, 3);
+
+results = new ArrayList<>();
+timeouts = new ArrayList<>();
+
+executor.onSuccess(new SuccessCallback() {
+  @Override
+  public void accept(DummyTask task, String result) {
+results.add(result);
+  }
+});
+
+executor.onTimeout(new TimeoutCallback() {
+  @Override
+  public void accept(DummyTask task) {
+timeouts.add(task);
+  }
+});
+
+executor.onException(new 
TimeoutTaskExecutor.ExceptionCallback() {
+  @Override
+  public void accept(DummyTask task, Exception e) {
+e.printStackTrace();
+fail("Unexpected exception");
+  }
+});
+  }
+
+  @Test
+  public void shouldExecuteTasks() throws InterruptedException {
+executor.submit(new DummyTask("one", 0));
+executor.submit(new DummyTask("two", 0));
+
+executor.complete();
+
+assertThat(results.contains("one"), is(true));
+assertThat(results.contains("two"), is(true));
+assertThat(timeouts.isEmpty(), is(true));
+  }
+
+  @Test
+  public void shouldReportTimedOutTasks() throws InterruptedException {
+executor.submit(new DummyTask("successful", 0));
+executor.submit(new DummyTask("timeout", timeout * 2));
+
+executor.complete();
+
+DummyTask task = Iterables.get(timeouts, 0);
+
+assertThat(timeouts.size(), is(1));
+assertThat(task.result, is("timeout"));
+  }
+
+  @Test
+  public void slowTasksShouldNotPreventOthersFromRunning() throws Exception {
+// Clog up the threadpool with slow running tasks
+executor.submit(new DummyTask("slow task 1", Long.MAX_VALUE));
+executor.submit(new DummyTask("slow task 2", Long.MAX_VALUE));
+executor.submit(new DummyTask("slow task 3", Long.MAX_VALUE));
+executor.submit(new DummyTask("good task", 0L));
+
+executor.complete();
+
+assertThat(results.size(), is(1));
+assertThat(Iterables.getFirst(results, null), is("good task"));
+  }
+
+  @After
+  public void tearDown() {
+executor.close();
+  }
+
+  private class DummyTask implements Callable {
+private final String result;
+private final long timeout;
+
+public DummyTask(String result, long timeout) {
+  this.result = result;
+  this.timeout = timeout;
+}
+
+@Override
+public String call() throws Exception {
+  Thread.sleep(timeout);
 
 Review comment:
   try changing this code to 
   
   ```java
   public String call() throws Exception {
 try {
   Thread.sleep(timeout);
 } catch (InterruptedException e) {
   Thread.sleep(timeout);
 }
 return result;
   }
   ```
   
   This simulates badly behaved code (some hadoop code used to swallow thread 
interrupts and keep going, not sure if it still does).  This will cause a test 
to fail because a non-slow task is canceled.

[GitHub] keith-turner commented on a change in pull request #402: ACCUMULO-4615: Updated get status for thread safety and with a per-task timeout

[GitBox]

keith-turner commented on a change in pull request #402: ACCUMULO-4615: Updated 
get status for thread safety and with a per-task timeout
URL: https://github.com/apache/accumulo/pull/402#discussion_r175576157
 
 

 ##
 File path: 
server/master/src/main/java/org/apache/accumulo/master/TimeoutTaskExecutor.java
 ##
 @@ -0,0 +1,198 @@
+/*
+ * 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.master;
+
+import java.util.ArrayList;
+import java.util.List;
+import java.util.Objects;
+import java.util.concurrent.Callable;
+import java.util.concurrent.ExecutorService;
+import java.util.concurrent.Future;
+import java.util.concurrent.TimeUnit;
+import java.util.concurrent.TimeoutException;
+
+import org.slf4j.Logger;
+import org.slf4j.LoggerFactory;
+
+import com.google.common.base.Preconditions;
+
+/**
+ * Runs one or more tasks with a timeout per task (instead of a timeout for 
the entire pool). Uses callbacks to invoke functions on successful, timed out, 
or
+ * tasks that error.
+ *
+ * @param 
+ *  The return type for the corresponding Callable.
+ * @param 
+ *  The type of Callable submitted to this executor.
+ */
+public class TimeoutTaskExecutor implements 
AutoCloseable {
+
+  private final static Logger log = 
LoggerFactory.getLogger(TimeoutTaskExecutor.class);
+
+  private final long timeout;
+  private final ExecutorService executorService;
+  private final List wrappedTasks;
+
+  private SuccessCallback successCallback;
+  private ExceptionCallback exceptionCallback;
+  private TimeoutCallback timeoutCallback;
+
+  /**
+   * Constructs a new TimeoutTaskExecutor using the given executor to schedule 
tasks with a max timeout. Takes an expected number of Callables to initialize 
the
+   * underlying task collection more appropriately.
+   *
+   * @param executorService
+   *  The executor to schedule tasks with.
+   * @param timeout
+   *  The timeout for each task.
+   * @param expectedNumCallables
+   *  The expected number of callables you will schedule (for sizing 
optimization).
+   */
+  public TimeoutTaskExecutor(ExecutorService executorService, long timeout, 
int expectedNumCallables) {
+this.executorService = executorService;
+this.timeout = timeout;
+this.wrappedTasks = new ArrayList<>(expectedNumCallables);
+  }
+
+  /**
+   * Submits a new task to the executor.
+   *
+   * @param callable
+   *  Task to run
+   */
+  public void submit(C callable) {
+WrappedTask wt = new WrappedTask(callable, 
executorService.submit(callable));
+wrappedTasks.add(wt);
+  }
+
+  /**
+   * Registers the callback to use on successful tasks.
+   *
+   * @param successCallback
+   *  The callback function to invoke on success.
+   * @throws NullPointerException
+   *   when a null successCallback is passed in
+   */
+  public void onSuccess(SuccessCallback successCallback) {
+this.successCallback = Objects.requireNonNull(successCallback, "Must 
provide a non-null successCallback.");
+  }
+
+  /**
+   * Registers the callback to use on tasks that throw exceptions.
+   *
+   * @param exceptionCallback
+   *  The callback function to invoke on exceptions.
+   * @throws NullPointerException
+   *   when a null exceptionCallback is passed in
+   */
+  public void onException(ExceptionCallback exceptionCallback) {
+this.exceptionCallback = Objects.requireNonNull(exceptionCallback, "Must 
provide a non-null exceptionCallback.");
+  }
+
+  /**
+   * Registers the callback to use on tasks that time out.
+   *
+   * @param timeoutCallback
+   *  The callback function to invoke on timeouts.
+   * @throws NullPointerException
+   *   when a null timeoutCallback is passed in
+   */
+  public void onTimeout(TimeoutCallback timeoutCallback) {
+this.timeoutCallback = Objects.requireNonNull(timeoutCallback, "Must 
provide a non-null timeoutCallback.");
+  }
+
+  /**
+   * Completes all the current tasks by dispatching to the appropriated 
callback.
+   *
+   * @throws IllegalStateException
+   *   If all of the callbacks were not registered before calling this 
method.
+   * 

[jira] [Resolved] (ACCUMULO-4820) Cleanup code for 2.0

[Christopher Tubbs (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ACCUMULO-4820?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christopher Tubbs resolved ACCUMULO-4820.
-
Resolution: Fixed

> Cleanup code for 2.0
> 
>
> Key: ACCUMULO-4820
> URL: https://issues.apache.org/jira/browse/ACCUMULO-4820
> Project: Accumulo
>  Issue Type: Improvement
>Affects Versions: 2.0.0
>Reporter: Michael Miller
>Assignee: Michael Miller
>Priority: Minor
>  Labels: pull-request-available
> Fix For: 2.0.0
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> Running IntelliJ code inspect picks up a lot of minor code clean up fixes 
> that we would be nice to fix sooner rather than later.
> Java 5 Updates 
> - unnecessary boxing
> - use foreach where possible
> Java 7 Updates (these should definitely be fixed)
> - Explicit type can be replaced with <> (aka diamond operator)
> - Identical catch branches in try 
> - try finally replaceable with try with resources
> Java 8 Updates (these would be nice, but maybe some prefer older way?)
> - Replace anonymous types with lambda
> - Replace code with new single Map method call
> - Replace Collections.sort () with List.sort()
> Other Misc performance Issues picked up by the inspector.  I think these 
> should definitely be fixed but perhaps a sub ticket



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (ACCUMULO-4820) Cleanup code for 2.0

[Christopher Tubbs (JIRA)]

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

Christopher Tubbs commented on ACCUMULO-4820:
-

The existing PR for this is merged, so I'm closing this as fixed. Now that 
we're using GitHub issues, if there's any follow-up work to be done, they can 
just be pull requests on GitHub.

> Cleanup code for 2.0
> 
>
> Key: ACCUMULO-4820
> URL: https://issues.apache.org/jira/browse/ACCUMULO-4820
> Project: Accumulo
>  Issue Type: Improvement
>Affects Versions: 2.0.0
>Reporter: Michael Miller
>Assignee: Michael Miller
>Priority: Minor
>  Labels: pull-request-available
> Fix For: 2.0.0
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> Running IntelliJ code inspect picks up a lot of minor code clean up fixes 
> that we would be nice to fix sooner rather than later.
> Java 5 Updates 
> - unnecessary boxing
> - use foreach where possible
> Java 7 Updates (these should definitely be fixed)
> - Explicit type can be replaced with <> (aka diamond operator)
> - Identical catch branches in try 
> - try finally replaceable with try with resources
> Java 8 Updates (these would be nice, but maybe some prefer older way?)
> - Replace anonymous types with lambda
> - Replace code with new single Map method call
> - Replace Collections.sort () with List.sort()
> Other Misc performance Issues picked up by the inspector.  I think these 
> should definitely be fixed but perhaps a sub ticket



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Assigned] (ACCUMULO-302) long lists in the monitor pages could be improved with summaries

[Christopher Tubbs (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ACCUMULO-302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christopher Tubbs reassigned ACCUMULO-302:
--

Assignee: Michael Miller

> long lists in the monitor pages could be improved with summaries
> 
>
> Key: ACCUMULO-302
> URL: https://issues.apache.org/jira/browse/ACCUMULO-302
> Project: Accumulo
>  Issue Type: Improvement
>  Components: monitor
> Environment: large clusters
>Reporter: Eric Newton
>Assignee: Michael Miller
>Priority: Critical
> Fix For: 2.0.0
>
>
> The many lists in the monitor display can take a long time to render: we need 
> summaries which display averages, std dev and show the top/bottom rows 
> completely.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (ACCUMULO-4791) setshelliter command has incorrect usage statement

[Mark Owens (JIRA)]

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

Mark Owens commented on ACCUMULO-4791:
--

yes, i've started looking at it.  

> setshelliter command has incorrect usage statement
> --
>
> Key: ACCUMULO-4791
> URL: https://issues.apache.org/jira/browse/ACCUMULO-4791
> Project: Accumulo
>  Issue Type: Bug
>  Components: shell
>Reporter: Mark Owens
>Assignee: Mark Owens
>Priority: Minor
> Fix For: 1.9.0, 2.0.0
>
>
> When using the Accumulo shell, the setshelliter command should not require a 
> table name and the usage indicates that a table name is optional, as 
> expected.   But the command will fail unless an existing table name is 
> supplied. Most likely due to the fact that setshelliter extends setiter, 
> which does require a valid table name.
> The setshelliter command should be updated to work as the current usage 
> indicates, i.e., no table name should be required.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (ACCUMULO-4791) setshelliter command has incorrect usage statement

[Christopher Tubbs (JIRA)]

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

Christopher Tubbs commented on ACCUMULO-4791:
-

[~jmark99], were you working on this?

> setshelliter command has incorrect usage statement
> --
>
> Key: ACCUMULO-4791
> URL: https://issues.apache.org/jira/browse/ACCUMULO-4791
> Project: Accumulo
>  Issue Type: Bug
>  Components: shell
>Reporter: Mark Owens
>Assignee: Mark Owens
>Priority: Minor
> Fix For: 1.9.0, 2.0.0
>
>
> When using the Accumulo shell, the setshelliter command should not require a 
> table name and the usage indicates that a table name is optional, as 
> expected.   But the command will fail unless an existing table name is 
> supplied. Most likely due to the fact that setshelliter extends setiter, 
> which does require a valid table name.
> The setshelliter command should be updated to work as the current usage 
> indicates, i.e., no table name should be required.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (ACCUMULO-4849) Hadoop2 Metrics do not retry sending if metrics server is down

[Christopher Tubbs (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ACCUMULO-4849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christopher Tubbs updated ACCUMULO-4849:

Fix Version/s: 2.0.0

> Hadoop2 Metrics do not retry sending if metrics server is down
> --
>
> Key: ACCUMULO-4849
> URL: https://issues.apache.org/jira/browse/ACCUMULO-4849
> Project: Accumulo
>  Issue Type: Bug
>Affects Versions: 2.0.0
>Reporter: Mike Walch
>Priority: Major
> Fix For: 2.0.0
>
>
> {code:java}
> 2018-03-16 11:01:14,726 [impl.MetricsSystemImpl] WARN : Error creating sink 
> 'graphite'
> org.apache.hadoop.metrics2.impl.MetricsConfigException: Error creating 
> plugin: org.apache.hadoop.metrics2.sink.GraphiteSink
> at 
> org.apache.hadoop.metrics2.impl.MetricsConfig.getPlugin(MetricsConfig.java:203)
> at 
> org.apache.hadoop.metrics2.impl.MetricsSystemImpl.newSink(MetricsSystemImpl.java:529)
> at 
> org.apache.hadoop.metrics2.impl.MetricsSystemImpl.configureSinks(MetricsSystemImpl.java:501)
> at 
> org.apache.hadoop.metrics2.impl.MetricsSystemImpl.configure(MetricsSystemImpl.java:480)
> at 
> org.apache.hadoop.metrics2.impl.MetricsSystemImpl.start(MetricsSystemImpl.java:189)
> at 
> org.apache.hadoop.metrics2.impl.MetricsSystemImpl.init(MetricsSystemImpl.java:164)
> at 
> org.apache.hadoop.metrics2.lib.DefaultMetricsSystem.init(DefaultMetricsSystem.java:54)
> at 
> org.apache.hadoop.metrics2.lib.DefaultMetricsSystem.initialize(DefaultMetricsSystem.java:50)
> at 
> org.apache.accumulo.server.metrics.MetricsSystemHelper$MetricsSystemHolder.(MetricsSystemHelper.java:46)
> at 
> org.apache.accumulo.server.metrics.MetricsSystemHelper.getInstance(MetricsSystemHelper.java:50)
> at 
> org.apache.accumulo.tserver.metrics.TabletServerMetricsFactory.(TabletServerMetricsFactory.java:45)
> at org.apache.accumulo.tserver.TabletServer.(TabletServer.java:401)
> at org.apache.accumulo.tserver.TabletServer.main(TabletServer.java:3086)
> at 
> org.apache.accumulo.tserver.TServerExecutable.execute(TServerExecutable.java:43)
> at org.apache.accumulo.start.Main.lambda$execKeyword$0(Main.java:122)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: org.apache.hadoop.metrics2.MetricsException: Error creating 
> connection, localhost:2004
> at 
> org.apache.hadoop.metrics2.sink.GraphiteSink$Graphite.connect(GraphiteSink.java:160)
> at org.apache.hadoop.metrics2.sink.GraphiteSink.init(GraphiteSink.java:64)
> at 
> org.apache.hadoop.metrics2.impl.MetricsConfig.getPlugin(MetricsConfig.java:199)
> ... 15 more
> Caused by: java.net.ConnectException: Connection refused (Connection refused)
> at java.net.PlainSocketImpl.socketConnect(Native Method)
> at 
> java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350)
> at 
> java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206)
> at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188)
> at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
> at java.net.Socket.connect(Socket.java:589)
> at java.net.Socket.connect(Socket.java:538)
> at java.net.Socket.(Socket.java:434)
> at java.net.Socket.(Socket.java:211)
> at 
> org.apache.hadoop.metrics2.sink.GraphiteSink$Graphite.connect(GraphiteSink.java:152)
> ... 17 more
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Accumulo-Master - Build # 2289 - Fixed

[Apache Jenkins Server]

The Apache Jenkins build system has built Accumulo-Master (build #2289)

Status: Fixed

Check console output at https://builds.apache.org/job/Accumulo-Master/2289/ to 
view the results.

Accumulo-1.7 - Build # 425 - Fixed

[Apache Jenkins Server]

The Apache Jenkins build system has built Accumulo-1.7 (build #425)

Status: Fixed

Check console output at https://builds.apache.org/job/Accumulo-1.7/425/ to view 
the results.

[GitHub] keith-turner commented on issue #394: ACCUMULO-4836 make online table always wait

[GitBox]

keith-turner commented on issue #394: ACCUMULO-4836 make online table always 
wait
URL: https://github.com/apache/accumulo/pull/394#issuecomment-374327567
 
 
   merged in c4f3685


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] keith-turner closed pull request #394: ACCUMULO-4836 make online table always wait

[GitBox]

keith-turner closed pull request #394: ACCUMULO-4836 make online table always 
wait
URL: https://github.com/apache/accumulo/pull/394
 
 
   

This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:

As this is a foreign pull request (from a fork), the diff is supplied
below (as it won't show otherwise due to GitHub magic):

diff --git 
a/core/src/main/java/org/apache/accumulo/core/client/impl/TableOperationsImpl.java
 
b/core/src/main/java/org/apache/accumulo/core/client/impl/TableOperationsImpl.java
index 0c3e0e6c60..7e42334ff8 100644
--- 
a/core/src/main/java/org/apache/accumulo/core/client/impl/TableOperationsImpl.java
+++ 
b/core/src/main/java/org/apache/accumulo/core/client/impl/TableOperationsImpl.java
@@ -1223,6 +1223,8 @@ public void online(String tableName, boolean wait) throws 
AccumuloSecurityExcept
 
 TableState expectedState = Tables.getTableState(context.getInstance(), 
tableId, true);
 if (expectedState == TableState.ONLINE) {
+  if (wait)
+waitForTableStateTransition(tableId, TableState.ONLINE);
   return;
 }
 


 


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[jira] [Resolved] (ACCUMULO-4836) Tables do not always wait for online or offline

[Keith Turner (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ACCUMULO-4836?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Keith Turner resolved ACCUMULO-4836.

Resolution: Fixed

> Tables do not always wait for online or offline
> ---
>
> Key: ACCUMULO-4836
> URL: https://issues.apache.org/jira/browse/ACCUMULO-4836
> Project: Accumulo
>  Issue Type: Bug
>Affects Versions: 1.7.3
>Reporter: Keith Turner
>Assignee: Keith Turner
>Priority: Major
>  Labels: pull-request-available
> Fix For: 1.7.4, 1.9.0, 2.0.0
>
>  Time Spent: 1h 20m
>  Remaining Estimate: 0h
>
> While investigating why TabletStateChangeIteratorIT it was discovered that 
> online table with wait=true does not always wait.  The test relied on this 
> API to wait and that is why it was failing.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (ACCUMULO-3667) Import Upgrade Tests project

[Christopher Tubbs (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ACCUMULO-3667?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christopher Tubbs resolved ACCUMULO-3667.
-
Resolution: Incomplete

There has been no activity on this issue in 20 months. I'm going to close this 
issue and the other upgrade-tests issues as "Incomplete". If activity resumes 
on this, it can be imported to a new gitbox repo or added to the existing 
'accumulo-testing' repo. Now that Accumulo is using GitHub for issue tracking, 
the issues can be added to the specific repository where this contribution is 
added.

> Import Upgrade Tests project
> 
>
> Key: ACCUMULO-3667
> URL: https://issues.apache.org/jira/browse/ACCUMULO-3667
> Project: Accumulo
>  Issue Type: Task
>  Components: upgrade-tests
>Reporter: Sean Busbey
>Assignee: Sean Busbey
>Priority: Major
> Fix For: upgrade-tests-1.0.0
>
>
> umbrella for tasks from the vote to establish  the contrib.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] mikewalch commented on a change in pull request #403: Fixes #404 Provide Grafana dashboard for metrics

[GitBox]

mikewalch commented on a change in pull request #403: Fixes #404 Provide 
Grafana dashboard for metrics
URL: https://github.com/apache/accumulo/pull/403#discussion_r175541676
 
 

 ##
 File path: assemble/pom.xml
 ##
 @@ -274,6 +274,15 @@
   
 
   
+  
+org.apache.rat
+apache-rat-plugin
+
+  
+conf/templates/grafana-dashboard.json
 
 Review comment:
   It has been removed.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[jira] [Resolved] (ACCUMULO-4557) Instance API should state when returning null is expected.

[Christopher Tubbs (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ACCUMULO-4557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christopher Tubbs resolved ACCUMULO-4557.
-
   Resolution: Not A Problem
Fix Version/s: (was: 1.7.4)
   (was: 1.9.0)
   (was: 2.0.0)

No response from the reporter. Closing as "Not A Problem" for now. Please 
create a new issue or pull request at https://github.com/apache/accumulo/issues 
if the problem persists.

> Instance API should state when returning null is expected.
> --
>
> Key: ACCUMULO-4557
> URL: https://issues.apache.org/jira/browse/ACCUMULO-4557
> Project: Accumulo
>  Issue Type: Bug
>  Components: client
>Affects Versions: 1.7.1, 1.7.2, 1.8.0
>Reporter: Sean Busbey
>Priority: Critical
>
> This is an issue at least in 1.6.0+. Ran into during ACCUMULO-4556.
> In that case the TablesServlet is making use of Instance to get root tablet 
> location information via the Instance interface. The API for 
> {{getRootTablet}} in master is:
> {code}
>   /**
>* Returns the location of the tablet server that is serving the root 
> tablet.
>*
>* @return location in "hostname:port" form
>*/
>   String getRootTabletLocation();
> {code}
> When the root tablet is offline, all of our current implementations return 
> {{null}}. The data structure used in TablesServlet can't handle nulls, so the 
> code fails with an NPE.
> We should review the current implementations for Instance and update the API 
> to include details on the circumstances where a {{null}} will be returned 
> from all of the defined methods.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (ACCUMULO-4705) Consider using security findbugs detectors

[Christopher Tubbs (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ACCUMULO-4705?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christopher Tubbs updated ACCUMULO-4705:

Fix Version/s: (was: 1.7.4)
   (was: 1.9.0)

> Consider using security findbugs detectors
> --
>
> Key: ACCUMULO-4705
> URL: https://issues.apache.org/jira/browse/ACCUMULO-4705
> Project: Accumulo
>  Issue Type: Improvement
>Reporter: Christopher Tubbs
>Priority: Major
> Fix For: 2.0.0
>
>
> findsecbugs-plugin is a findbugs plugin to detect potential security bugs in 
> Java code.
> We should consider using this in our builds, at the very least, to triage 
> potential security issues.
> In the findbugs plugin's configuration section, we'd add:
> {code}
>   
> ...
> 
>   com.h3xstream.findsecbugs
>   findsecbugs-plugin
>   1.7.1
> 
>   
> {code}
> See their website for details and docs: http://find-sec-bugs.github.io/



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (ACCUMULO-3830) Repeated attempts to bind already bound port in tserver

[Christopher Tubbs (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ACCUMULO-3830?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christopher Tubbs resolved ACCUMULO-3830.
-
   Resolution: Invalid
Fix Version/s: (was: 1.7.4)
   (was: 1.9.0)
   (was: 2.0.0)

Closing as "Invalid", superseded by ACCUMULO-4331, based on last comment. 
Please create a new issue or pull request at 
https://github.com/apache/accumulo/issues if the problem persists.

> Repeated attempts to bind already bound port in tserver
> ---
>
> Key: ACCUMULO-3830
> URL: https://issues.apache.org/jira/browse/ACCUMULO-3830
> Project: Accumulo
>  Issue Type: Bug
>  Components: tserver
>Reporter: Josh Elser
>Assignee: Josh Elser
>Priority: Minor
>
> {noformat}
> 2015-05-19 17:56:00,792 [client.ClientConfiguration] WARN : Client 
> configuration constructed with a Configuration that did not have list 
> delimiter disabled or overridden, multi-valued config properties may be 
> unavailable
> 2015-05-19 17:56:00,793 [rpc.TServerUtils] DEBUG: Instantiating SASL Thrift 
> server
> 2015-05-19 17:56:00,793 [rpc.TServerUtils] INFO : Creating SASL thread pool 
> thrift server on listening on hostname:9997
> 2015-05-19 17:56:00,793 [rpc.TServerUtils] ERROR: Unable to start TServer
> org.apache.thrift.transport.TTransportException: Could not create 
> ServerSocket on address 0.0.0.0/0.0.0.0:9997.
> at 
> org.apache.thrift.transport.TServerSocket.(TServerSocket.java:93)
> at 
> org.apache.thrift.transport.TServerSocket.(TServerSocket.java:75)
> at 
> org.apache.accumulo.server.rpc.TServerUtils.createSaslThreadPoolServer(TServerUtils.java:388)
> at 
> org.apache.accumulo.server.rpc.TServerUtils.startTServer(TServerUtils.java:498)
> at 
> org.apache.accumulo.server.rpc.TServerUtils.startTServer(TServerUtils.java:472)
> at 
> org.apache.accumulo.server.rpc.TServerUtils.startServer(TServerUtils.java:151)
> at 
> org.apache.accumulo.tserver.TabletServer.startServer(TabletServer.java:2266)
> at 
> org.apache.accumulo.tserver.TabletServer.startTabletClientService(TabletServer.java:2314)
> at 
> org.apache.accumulo.tserver.TabletServer.run(TabletServer.java:2450)
> at 
> org.apache.accumulo.tserver.TabletServer$9.run(TabletServer.java:2963)
> at 
> org.apache.accumulo.tserver.TabletServer$9.run(TabletServer.java:2960)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:415)
> at 
> org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1657)
> at 
> org.apache.accumulo.tserver.TabletServer.main(TabletServer.java:2960)
> at 
> org.apache.accumulo.tserver.TServerExecutable.execute(TServerExecutable.java:33)
> at org.apache.accumulo.start.Main$1.run(Main.java:93)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
> I'm seeing loops of 100 of the above when a tabletserver tries to start on a 
> node in which it's already running. I think this is the port-shift code that 
> tries to jump around and choose a different value. When we have a static 
> value, trying to jump around is rather useless.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (ACCUMULO-4197) Intermittent failure of HalfDeadTServerIT

[Christopher Tubbs (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ACCUMULO-4197?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christopher Tubbs resolved ACCUMULO-4197.
-
   Resolution: Cannot Reproduce
Fix Version/s: (was: 1.7.4)
   (was: 1.9.0)
   (was: 2.0.0)

Haven't been able to reproduce this one. Please create a new issue or pull 
request at https://github.com/apache/accumulo/issues if the problem persists.

> Intermittent failure of HalfDeadTServerIT
> -
>
> Key: ACCUMULO-4197
> URL: https://issues.apache.org/jira/browse/ACCUMULO-4197
> Project: Accumulo
>  Issue Type: Bug
>  Components: test
>Reporter: Josh Elser
>Priority: Minor
>
> I observed an intermittent failure of HalfDeadTServerIT#testRecover today.
> This test "injects" pauses to the C read and write calls inside of tserver. 
> testRecover injects a pause of 10 seconds to show that the TServer can 
> reconnect to ZK (and not lose its session).
> However, with an RPC timeout of 5 seconds, if a minor compaction is 
> triggered, this pause will cause a compaction to take >10 seconds which will 
> trigger the "hold timeout" causing an exception to be thrown to the client.
> {noformat}
> 2016-04-20 03:39:26,999 [tserver.TabletServer$ThriftClientHandler] ERROR: 
> Commits are held
> org.apache.accumulo.tserver.HoldTimeoutException: Commits are held
>   at 
> org.apache.accumulo.tserver.TabletServerResourceManager.waitUntilCommitsAreEnabled(TabletServerResourceManager.java:493)
>   at 
> org.apache.accumulo.tserver.TabletServer$ThriftClientHandler.flush(TabletServer.java:805)
>   at 
> org.apache.accumulo.tserver.TabletServer$ThriftClientHandler.closeUpdate(TabletServer.java:962)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:498)
>   at 
> org.apache.accumulo.core.trace.wrappers.RpcServerInvocationHandler.invoke(RpcServerInvocationHandler.java:46)
>   at 
> org.apache.accumulo.server.rpc.RpcWrapper$1.invoke(RpcWrapper.java:73)
>   at com.sun.proxy.$Proxy21.closeUpdate(Unknown Source)
>   at 
> org.apache.accumulo.core.tabletserver.thrift.TabletClientService$Processor$closeUpdate.getResult(TabletClientService.java:2446)
>   at 
> org.apache.accumulo.core.tabletserver.thrift.TabletClientService$Processor$closeUpdate.getResult(TabletClientService.java:2430)
>   at org.apache.thrift.ProcessFunction.process(ProcessFunction.java:39)
>   at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:39)
>   at 
> org.apache.accumulo.server.rpc.TimedProcessor.process(TimedProcessor.java:63)
>   at 
> org.apache.thrift.server.AbstractNonblockingServer$FrameBuffer.invoke(AbstractNonblockingServer.java:516)
>   at 
> org.apache.accumulo.server.rpc.CustomNonBlockingServer$1.run(CustomNonBlockingServer.java:78)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>   at 
> org.apache.accumulo.fate.util.LoggingRunnable.run(LoggingRunnable.java:35)
>   at java.lang.Thread.run(Thread.java:745)
> {noformat}
> I believe this is intermittent based on whether or not a minor compaction is 
> triggered after the i/o pausing is triggered or not. We could probably work 
> around this by increasing the threshold for running a minor compaction.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (ACCUMULO-3854) [findbugs] AsyncSpanReceiver synchronizes a concurrent data structure

[Christopher Tubbs (JIRA)]

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

Christopher Tubbs commented on ACCUMULO-3854:
-

>From reading this, it's not clear to me that this is an actual concurrency 
>problem, or just a false positive from findbugs as a result of a generally bad 
>practice. If the latter, I think it's probably okay that we're not triggering 
>the false positive from findbugs by using the parent class. If the former, 
>please describe the concurrency issue that this can cause.

> [findbugs] AsyncSpanReceiver synchronizes a concurrent data structure
> -
>
> Key: ACCUMULO-3854
> URL: https://issues.apache.org/jira/browse/ACCUMULO-3854
> Project: Accumulo
>  Issue Type: Bug
>  Components: trace
>Affects Versions: 1.5.0, 1.5.1, 1.5.2, 1.6.0, 1.6.1, 1.6.2, 1.7.0
>Reporter: Josh Elser
>Priority: Minor
>  Labels: findbugs
> Fix For: 1.9.0, 2.0.0
>
>
> Noticed this one playing around with ACCUMULO-3853
> If the type of {{sendQueue}} is switched to the concrete 
> ConcurrentLinkedQueue instead of AbstractQueue, findbugs will catch this as 
> an error because we synchronize on a concurrent data structure.
> {code}
> -  protected final AbstractQueue sendQueue = new 
> ConcurrentLinkedQueue();
> +  protected final ConcurrentLinkedQueue sendQueue = new 
> ConcurrentLinkedQueue();
> {code}
> Should trigger some findbugs warnings from the Maven build.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (ACCUMULO-3854) [findbugs] AsyncSpanReceiver synchronizes a concurrent data structure

[Christopher Tubbs (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ACCUMULO-3854?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christopher Tubbs updated ACCUMULO-3854:

Fix Version/s: (was: 1.7.4)

> [findbugs] AsyncSpanReceiver synchronizes a concurrent data structure
> -
>
> Key: ACCUMULO-3854
> URL: https://issues.apache.org/jira/browse/ACCUMULO-3854
> Project: Accumulo
>  Issue Type: Bug
>  Components: trace
>Affects Versions: 1.5.0, 1.5.1, 1.5.2, 1.6.0, 1.6.1, 1.6.2, 1.7.0
>Reporter: Josh Elser
>Priority: Minor
>  Labels: findbugs
> Fix For: 1.9.0, 2.0.0
>
>
> Noticed this one playing around with ACCUMULO-3853
> If the type of {{sendQueue}} is switched to the concrete 
> ConcurrentLinkedQueue instead of AbstractQueue, findbugs will catch this as 
> an error because we synchronize on a concurrent data structure.
> {code}
> -  protected final AbstractQueue sendQueue = new 
> ConcurrentLinkedQueue();
> +  protected final ConcurrentLinkedQueue sendQueue = new 
> ConcurrentLinkedQueue();
> {code}
> Should trigger some findbugs warnings from the Maven build.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Updated] (ACCUMULO-3854) [findbugs] AsyncSpanReceiver synchronizes a concurrent data structure

[Christopher Tubbs (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ACCUMULO-3854?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christopher Tubbs updated ACCUMULO-3854:

Component/s: trace

> [findbugs] AsyncSpanReceiver synchronizes a concurrent data structure
> -
>
> Key: ACCUMULO-3854
> URL: https://issues.apache.org/jira/browse/ACCUMULO-3854
> Project: Accumulo
>  Issue Type: Bug
>  Components: trace
>Affects Versions: 1.5.0, 1.5.1, 1.5.2, 1.6.0, 1.6.1, 1.6.2, 1.7.0
>Reporter: Josh Elser
>Priority: Minor
>  Labels: findbugs
> Fix For: 1.7.4, 1.9.0, 2.0.0
>
>
> Noticed this one playing around with ACCUMULO-3853
> If the type of {{sendQueue}} is switched to the concrete 
> ConcurrentLinkedQueue instead of AbstractQueue, findbugs will catch this as 
> an error because we synchronize on a concurrent data structure.
> {code}
> -  protected final AbstractQueue sendQueue = new 
> ConcurrentLinkedQueue();
> +  protected final ConcurrentLinkedQueue sendQueue = new 
> ConcurrentLinkedQueue();
> {code}
> Should trigger some findbugs warnings from the Maven build.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (ACCUMULO-4556) Monitor shows stack trace for NPE while viewing table details for accumulo.root if tablet is offline

[Christopher Tubbs (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ACCUMULO-4556?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christopher Tubbs resolved ACCUMULO-4556.
-
   Resolution: Fixed
Fix Version/s: (was: 1.7.4)
   (was: 1.9.0)

I believe this was fixed in 2.0 with ACCUMULO-3005. Please open a new issue at 
https://github.com/apache/accumulo/issues if it persists.

> Monitor shows stack trace for NPE while viewing table details for 
> accumulo.root if tablet is offline
> 
>
> Key: ACCUMULO-4556
> URL: https://issues.apache.org/jira/browse/ACCUMULO-4556
> Project: Accumulo
>  Issue Type: Bug
>  Components: monitor
>Affects Versions: 1.7.1, 1.7.2, 1.8.0
>Reporter: Sean Busbey
>Priority: Major
>  Labels: beginner
> Fix For: 2.0.0
>
>
> AFAICT this is a problem in atleast 1.6.0 - current master (2.0-SNAPSHOT)
> Noticed this while debugging a cluster with offline root tablet:
> monitor -> Tables -> (shows accumulo.root with 1 offline tablet) -> 
> accumulo.root ->
> {code}
> java.lang.NullPointerException
>   at java.util.TreeMap.compare(TreeMap.java:1188)
>   at java.util.TreeMap.put(TreeMap.java:531)
>   at java.util.TreeSet.add(TreeSet.java:255)
>   at 
> org.apache.accumulo.monitor.servlets.TablesServlet.doTableDetails(TablesServlet.java:152)
>   at 
> org.apache.accumulo.monitor.servlets.TablesServlet.pageBody(TablesServlet.java:75)
>   at 
> org.apache.accumulo.monitor.servlets.BasicServlet.doGet(BasicServlet.java:65)
>   at javax.servlet.http.HttpServlet.service(HttpServlet.java:707)
>   at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
>   at 
> org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:511)
>   at 
> org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:401)
>   at 
> org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:182)
>   at 
> org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:767)
>   at 
> org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:230)
>   at 
> org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
>   at org.mortbay.jetty.Server.handle(Server.java:326)
>   at 
> org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:542)
>   at 
> org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:928)
>   at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:549)
>   at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:212)
>   at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404)
>   at 
> org.mortbay.jetty.bio.SocketConnector$Connection.run(SocketConnector.java:228)
>   at 
> org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:582)
> {code}
> Looking at master branch our handling in TablesServlet looks like
> {code}
>   private void doTableDetails(HttpServletRequest req, StringBuilder sb, 
> Map tidToNameMap, String tableId) {
> String displayName = Tables.getPrintableTableNameFromId(tidToNameMap, 
> tableId);
> Instance instance = Monitor.getContext().getInstance();
> TreeSet locs = new TreeSet<>();
> if (RootTable.ID.equals(tableId)) {
>   locs.add(instance.getRootTabletLocation());
> } else {
> ...
> {code}
> The Instance API doesn't say it, but all of our current implementations 
> return {{null}} for {{getRootTabletLocation}} when the root tablet is 
> offline. Since we create {{locs}} with the empty constructor, it uses natural 
> ordering and doesn't allow {{null}} members, so things explode.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Resolved] (ACCUMULO-3892) Problematic ITs

[Christopher Tubbs (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ACCUMULO-3892?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Christopher Tubbs resolved ACCUMULO-3892.
-
   Resolution: Cannot Reproduce
Fix Version/s: (was: 1.7.4)
   (was: 1.9.0)
   (was: 2.0.0)

Haven't seen these tests fail in awhile. Please re-create a new issue at 
https://github.com/apache/accumulo/issues if they persist.

> Problematic ITs
> ---
>
> Key: ACCUMULO-3892
> URL: https://issues.apache.org/jira/browse/ACCUMULO-3892
> Project: Accumulo
>  Issue Type: Bug
>  Components: test
>Affects Versions: 1.7.0
>Reporter: Josh Elser
>Priority: Minor
>
> There are a few tests that I've regularly seem not want to pass during 
> nightly automated testing.
> {noformat}
> E AssertionError: test timed out after 30 milliseconds
> E java.lang.Exception: test timed out after 30 milliseconds
> E at java.lang.Thread.sleep(Native Method)
> E at 
> org.apache.accumulo.core.util.UtilWaitThread.sleep(UtilWaitThread.java:27)
> E at 
> org.apache.accumulo.core.client.impl.TableOperationsImpl.waitForTableStateTransition(TableOperationsImpl.java:1159)
> E at 
> org.apache.accumulo.core.client.impl.TableOperationsImpl.online(TableOperationsImpl.java:1223)
> E at 
> org.apache.accumulo.test.AssignmentThreadsIT.testConcurrentAssignmentPerformance(AssignmentThreadsIT.java:77)
> {noformat}
> {noformat}
> E AssertionError: test timed out after 9 milliseconds
> E java.lang.Exception: test timed out after 9 milliseconds
> E at sun.misc.Unsafe.park(Native Method)
> E at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:226)
> E at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedNanos(AbstractQueuedSynchronizer.java:1033)
> E at 
> java.util.concurrent.locks.AbstractQueuedSynchronizer.tryAcquireSharedNanos(AbstractQueuedSynchronizer.java:1326)
> E at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:282)
> E at 
> org.apache.accumulo.core.client.impl.TableOperationsImpl.addSplits(TableOperationsImpl.java:388)
> E at org.apache.accumulo.test.BalanceFasterIT.test(BalanceFasterIT.java:60)
> {noformat}
> {noformat}
> E AssertionError: test timed out after 36 milliseconds
> E java.lang.Exception: test timed out after 36 milliseconds
> E at java.lang.Object.wait(Native Method)
> E at java.lang.Thread.join(Thread.java:1281)
> E at java.lang.Thread.join(Thread.java:1355)
> E at 
> org.apache.accumulo.test.InterruptibleScannersIT.test(InterruptibleScannersIT.java:98)
> {noformat}
> {noformat}
> E AssertionError: test timed out after 144 milliseconds
> E java.lang.Exception: test timed out after 144 milliseconds
> E at java.lang.Object.wait(Native Method)
> E at java.lang.Object.wait(Object.java:503)
> E at java.lang.UNIXProcess.waitFor(UNIXProcess.java:263)
> E at 
> org.apache.accumulo.test.functional.MetadataMaxFilesIT.test(MetadataMaxFilesIT.java:84)
> {noformat}
> This is with a quadrupled timeout (if not 8x by now). I know these tests all 
> _can_ pass (as I ensured that doing 1.7.0 testing), but apparently something 
> isn't good enough when running on a EC2 m1.xlarges IIRC. I believe all of 
> these tests are stretching the bounds on what is really suitable for an 
> integration test, IMO. Perhaps there is a better way to write the test and 
> verify the correctness that we want expect to see, but these tests are 
> definitely not reliably testing what we hope they are for me.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[GitHub] ctubbsii commented on a change in pull request #403: Fixes #404 Provide Grafana dashboard for metrics

[GitBox]

ctubbsii commented on a change in pull request #403: Fixes #404 Provide Grafana 
dashboard for metrics
URL: https://github.com/apache/accumulo/pull/403#discussion_r175528376
 
 

 ##
 File path: assemble/pom.xml
 ##
 @@ -274,6 +274,15 @@
   
 
   
+  
+org.apache.rat
+apache-rat-plugin
+
+  
+conf/templates/grafana-dashboard.json
 
 Review comment:
   This isn't needed anymore.


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

[GitHub] keith-turner commented on issue #402: ACCUMULO-4615: Updated get status for thread safety and with a per-task timeout

[GitBox]

keith-turner commented on issue #402: ACCUMULO-4615: Updated get status for 
thread safety and with a per-task timeout
URL: https://github.com/apache/accumulo/pull/402#issuecomment-374296645
 
 
   https://issues.apache.org/jira/browse/ACCUMULO-4615


This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

Accumulo-Master - Build # 2288 - Unstable

[Apache Jenkins Server]

The Apache Jenkins build system has built Accumulo-Master (build #2288)

Status: Unstable

Check console output at https://builds.apache.org/job/Accumulo-Master/2288/ to 
view the results.

[jira] [Updated] (ACCUMULO-4615) ThreadPool timeout when checking tserver stats is confusing

[Jeff Schmidt (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ACCUMULO-4615?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeff Schmidt updated ACCUMULO-4615:
---
Status: Patch Available  (was: Open)

> ThreadPool timeout when checking tserver stats is confusing
> ---
>
> Key: ACCUMULO-4615
> URL: https://issues.apache.org/jira/browse/ACCUMULO-4615
> Project: Accumulo
>  Issue Type: Bug
>  Components: master
>Affects Versions: 1.8.1
>Reporter: Michael Wall
>Assignee: Jeff Schmidt
>Priority: Minor
>  Labels: pull-request-available
> Fix For: 1.9.0, 2.0.0
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> If it takes longer than the configured time to gather information from all 
> the tablet servers, the thread pool stops and processing continues with 
> whatever has been collected.  Code is 
> https://github.com/apache/accumulo/blob/1.8/server/master/src/main/java/org/apache/accumulo/master/Master.java#L1120,
>  default timeout is 6s.  Does not appear to be an issue prior to 1.8.
> Best case, this was really confusing.  The monitor page would have 30 
> tservers, then 5 tservers.  Didn't really see any other negative effects, no 
> migrations and no balancing appeared to be affected.  Worse case though, I 
> missed something and the master is making decisions based on incomplete 
> information.
> [~dlmar...@comcast.net] please add more info if needed.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)