You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@accumulo.apache.org by "Dave Marion (JIRA)" <ji...@apache.org> on 2017/03/28 19:54:41 UTC
[jira] [Commented] (ACCUMULO-4615) ThreadPool timeout when checking
tserver stats is confusing
[ https://issues.apache.org/jira/browse/ACCUMULO-4615?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15945815#comment-15945815 ]
Dave Marion commented on ACCUMULO-4615:
---------------------------------------
[~mjwall] You got most of it, basically the monitoring was freaking out, showing different values for # tservers, # tablets, # offline tables. Default timeout is 2 * client timeout (default 3s). Not sure if increasing the client timeout will cause other issues, or if we should be using a different property.
> 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
> Priority: Minor
>
> 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.
> [~dlmarion@comcast.net] please add more info if needed.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)