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 5D8A21835B for ; Wed, 9 Dec 2015 08:24:11 +0000 (UTC) Received: (qmail 91458 invoked by uid 500); 9 Dec 2015 08:24:11 -0000 Delivered-To: apmail-hbase-issues-archive@hbase.apache.org Received: (qmail 91403 invoked by uid 500); 9 Dec 2015 08:24:11 -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 91377 invoked by uid 99); 9 Dec 2015 08:24:11 -0000 Received: from arcas.apache.org (HELO arcas) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 09 Dec 2015 08:24:11 +0000 Received: from arcas.apache.org (localhost [127.0.0.1]) by arcas (Postfix) with ESMTP id EEDEF2C14F9 for ; Wed, 9 Dec 2015 08:24:10 +0000 (UTC) Date: Wed, 9 Dec 2015 08:24:10 +0000 (UTC) From: "Elliott Clark (JIRA)" To: issues@hbase.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Commented] (HBASE-14946) Don't allow multi's to over run the max result size. 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-14946?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15048276#comment-15048276 ] Elliott Clark commented on HBASE-14946: --------------------------------------- bq.It is not important that it be accurate? Not 100% accurate. Just making sure to get an estimate of the size. If we're off by a byte here or there it's not a big deal. bq.Volatile? Or it don't matter? Or one thread only? One thread only. bq.throw new HBaseIOException("Response size would be too large"); Can do. bq.So, we are going to break the client response? How do they get the full response back? Needs admin intervention? The async process should retry all failed gets. Let me get a test to show that. bq.Why does the scanner chunking not help here? Multi actions won't contain scans. And we don't chunk on anything where is isGetScan is true. > Don't allow multi's to over run the max result size. > ---------------------------------------------------- > > Key: HBASE-14946 > URL: https://issues.apache.org/jira/browse/HBASE-14946 > Project: HBase > Issue Type: Improvement > Affects Versions: 2.0.0, 1.2.0, 1.3.0 > Reporter: Elliott Clark > Assignee: Elliott Clark > Priority: Critical > Attachments: HBASE-14946-v1.patch, HBASE-14946-v2.patch, HBASE-14946-v3.patch, HBASE-14946-v5.patch, HBASE-14946.patch > > > If a user puts a list of tons of different gets into a table we will then send them along in a multi. The server un-wraps each get in the multi. While no single get may be over the size limit the total might be. > We should protect the server from this. > We should batch up on the server side so each RPC is smaller. -- This message was sent by Atlassian JIRA (v6.3.4#6332)