Return-Path: X-Original-To: apmail-hbase-issues-archive@www.apache.org Delivered-To: apmail-hbase-issues-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 4FBDDD449 for ; Sat, 20 Oct 2012 15:22:15 +0000 (UTC) Received: (qmail 53785 invoked by uid 500); 20 Oct 2012 15:22:14 -0000 Delivered-To: apmail-hbase-issues-archive@hbase.apache.org Received: (qmail 53497 invoked by uid 500); 20 Oct 2012 15:22:14 -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 53476 invoked by uid 99); 20 Oct 2012 15:22:13 -0000 Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 20 Oct 2012 15:22:13 +0000 Date: Sat, 20 Oct 2012 15:22:13 +0000 (UTC) From: "Ted Yu (JIRA)" To: issues@hbase.apache.org Message-ID: <938677104.5595.1350746533825.JavaMail.jiratomcat@arcas> In-Reply-To: <105672331.45644.1346954587553.JavaMail.jiratomcat@arcas> Subject: [jira] [Updated] (HBASE-6728) [89-fb] prevent OOM possibility due to per connection responseQueue being unbounded 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/HBASE-6728?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Yu updated HBASE-6728: -------------------------- Attachment: 6728-trunk.txt > [89-fb] prevent OOM possibility due to per connection responseQueue being unbounded > ----------------------------------------------------------------------------------- > > Key: HBASE-6728 > URL: https://issues.apache.org/jira/browse/HBASE-6728 > Project: HBase > Issue Type: Bug > Reporter: Kannan Muthukkaruppan > Assignee: Michal Gregorczyk > Fix For: 0.96.0 > > Attachments: 6728-trunk.txt > > > The per connection responseQueue is an unbounded queue. The request handler threads today try to send the response in line, but if things start to backup, the response is sent via a per connection responder thread. This intermediate queue, because it has no bounds, can be another source of OOMs. > [Have not looked at this issue in trunk. So it may or may not be applicable there.] -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira