Return-Path: X-Original-To: apmail-accumulo-notifications-archive@minotaur.apache.org Delivered-To: apmail-accumulo-notifications-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 1005617AD3 for ; Tue, 27 Oct 2015 20:30:31 +0000 (UTC) Received: (qmail 78316 invoked by uid 500); 27 Oct 2015 20:30:28 -0000 Delivered-To: apmail-accumulo-notifications-archive@accumulo.apache.org Received: (qmail 78253 invoked by uid 500); 27 Oct 2015 20:30:28 -0000 Mailing-List: contact notifications-help@accumulo.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: jira@apache.org Delivered-To: mailing list notifications@accumulo.apache.org Received: (qmail 78220 invoked by uid 99); 27 Oct 2015 20:30:27 -0000 Received: from arcas.apache.org (HELO arcas) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 27 Oct 2015 20:30:27 +0000 Received: from arcas.apache.org (localhost [127.0.0.1]) by arcas (Postfix) with ESMTP id B71D52C1F58 for ; Tue, 27 Oct 2015 20:30:27 +0000 (UTC) Date: Tue, 27 Oct 2015 20:30:27 +0000 (UTC) From: "Ivan Bella (JIRA)" To: notifications@accumulo.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Commented] (ACCUMULO-4039) try out a proactor design pattern for tserver services MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/ACCUMULO-4039?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14977101#comment-14977101 ] Ivan Bella commented on ACCUMULO-4039: -------------------------------------- Fair enough, the Thrift threadpools need to be bounded as well.... > try out a proactor design pattern for tserver services > ------------------------------------------------------ > > Key: ACCUMULO-4039 > URL: https://issues.apache.org/jira/browse/ACCUMULO-4039 > Project: Accumulo > Issue Type: Improvement > Components: tserver > Reporter: Adam Fuchs > Priority: Minor > > For large instances (i.e. lots of clients for a given tserver) we create oodles of threads on the tserver. This makes for difficulty in predicting performance, memory usage, etc. Moreover, we have operations that recurse, like a server querying itself, that we currently solve by having separate thread pools for regular table operations and metadata table operations, and we "disallow" things like an iterator writing to another table. One alternative option would be to switch to a Proactor pattern: https://en.wikipedia.org/wiki/Proactor_pattern > The core of this would be to switch to using a selection set rather than a thread per active connection, and then wrap everything in sessions that make progress in something like a state model, with states that account for asynchronous communications and remote work. -- This message was sent by Atlassian JIRA (v6.3.4#6332)