Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Date: Fri, 7 Sep 2012 10:39:07 +1100 (NCT)
From: "Kannan Muthukkaruppan (JIRA)" <jira@apache.org>
To: issues@hbase.apache.org
Message-ID: <819834986.47330.1346974747989.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


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

Kannan Muthukkaruppan updated HBASE-6728:
-----------------------------------------

    Description: 
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.]

  was:
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. The intermediate queue used in between has no bound either, and can be another source of OOMs.

[Have not looked at this issue in trunk. So it may or may not be applicable there.]

    
> [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: Kannan Muthukkaruppan
>
> 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