Return-Path: X-Original-To: archive-asf-public-internal@cust-asf2.ponee.io Delivered-To: archive-asf-public-internal@cust-asf2.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by cust-asf2.ponee.io (Postfix) with ESMTP id 5BA50200B27 for ; Wed, 22 Jun 2016 11:06:00 +0200 (CEST) Received: by cust-asf.ponee.io (Postfix) id 5A4AA160A2E; Wed, 22 Jun 2016 09:06:00 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id A228E160A64 for ; Wed, 22 Jun 2016 11:05:59 +0200 (CEST) Received: (qmail 30392 invoked by uid 500); 22 Jun 2016 09:05:58 -0000 Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Delivered-To: mailing list issues@hbase.apache.org Received: (qmail 29971 invoked by uid 99); 22 Jun 2016 09:05:58 -0000 Received: from arcas.apache.org (HELO arcas) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 22 Jun 2016 09:05:58 +0000 Received: from arcas.apache.org (localhost [127.0.0.1]) by arcas (Postfix) with ESMTP id 461212C1F78 for ; Wed, 22 Jun 2016 09:05:58 +0000 (UTC) Date: Wed, 22 Jun 2016 09:05:58 +0000 (UTC) From: "Elliott Clark (JIRA)" To: issues@hbase.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Commented] (HBASE-15146) Don't block on Reader threads queueing to a scheduler queue MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 archived-at: Wed, 22 Jun 2016 09:06:00 -0000 [ https://issues.apache.org/jira/browse/HBASE-15146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15343958#comment-15343958 ] Elliott Clark commented on HBASE-15146: --------------------------------------- bq.That seems based on the fact that there are some clients which don't wait the response of the previously sent request Nope, it's all about pushing back before blocking on queueing things that can't be answered in a reasonable time. You can get the queue full with enough single clients. The reader is non-blocking. The fact that we were blocking and not acking tcp streams until after full requests are completed was not a preformance benefit in any way. It was just wrong. It lost perf in multiple different ways. To see this in the extreme set the handlers to one, and the call queue length to one. Then tcpdump and see what happens. > Don't block on Reader threads queueing to a scheduler queue > ----------------------------------------------------------- > > Key: HBASE-15146 > URL: https://issues.apache.org/jira/browse/HBASE-15146 > Project: HBase > Issue Type: Bug > Affects Versions: 1.2.0 > Reporter: Elliott Clark > Assignee: Elliott Clark > Priority: Blocker > Fix For: 2.0.0, 1.2.0, 1.3.0 > > Attachments: HBASE-15146-v7.patch, HBASE-15146-v8.patch, HBASE-15146-v8.patch, HBASE-15146.0.patch, HBASE-15146.1.patch, HBASE-15146.2.patch, HBASE-15146.3.patch, HBASE-15146.4.patch, HBASE-15146.5.patch, HBASE-15146.6.patch > > > Blocking on the epoll thread is awful. The new rpc scheduler can have lots of different queues. Those queues have different capacity limits. Currently the dispatch method can block trying to add the the blocking queue in any of the schedulers. > This causes readers to block, tcp acks are delayed, and everything slows down. -- This message was sent by Atlassian JIRA (v6.3.4#6332)