Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Date: Tue, 23 Oct 2012 23:02:12 +0000 (UTC)
From: "Jesse Yates (JIRA)" <jira@apache.org>
To: issues@hbase.apache.org
Message-ID: <2020712182.18876.1351033332957.JavaMail.jiratomcat@arcas>
In-Reply-To: 
 <225621670.23806.1326155800145.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Commented] (HBASE-5162) Basic client pushback mechanism
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/HBASE-5162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13482785#comment-13482785 ] 

Jesse Yates commented on HBASE-5162:
------------------------------------

[~jxiang] not really - the exception causes old clients to fail and uses exception type inheritance + instanceof checking to get the information across. The client code does need minimal change (see my attached patch), but it just feels _dirty_, especially when we have PBs for everythign. What would be far better is just pass that info back as an optional PB parameter and have the client monitor it or not. This both works the the older versions AND optionally turning it off on the client if your workload needs it. the workload doesn't stay the same - the client gets constant information (at least with each mutation across the wire) back from the region and adjusts as it's updated.

 So yeah, every client that has this enabled would have to track the information. But you could make it that you just track the most recent 'n' regions. And an advanced version would also do some load half-life mechanism on the client if it hasn't talked to that region in a while.
                
> Basic client pushback mechanism
> -------------------------------
>
>                 Key: HBASE-5162
>                 URL: https://issues.apache.org/jira/browse/HBASE-5162
>             Project: HBase
>          Issue Type: New Feature
>    Affects Versions: 0.92.0
>            Reporter: Jean-Daniel Cryans
>             Fix For: 0.96.0
>
>         Attachments: java_HBASE-5162.patch
>
>
> The current blocking we do when we are close to some limits (memstores over the multiplier factor, too many store files, global memstore memory) is bad, too coarse and confusing. After hitting HBASE-5161, it really becomes obvious that we need something better.
> I did a little brainstorm with Stack, we came up quickly with two solutions:
>  - Send some exception to the client, like OverloadedException, that's thrown when some situation happens like getting past the low memory barrier. It would be thrown when the client gets a handler and does some check while putting or deleting. The client would treat this a retryable exception but ideally wouldn't check .META. for a new location. It could be fancy and have multiple levels of pushback, like send the exception to 25% of the clients, and then go up if the situation persists. Should be "easy" to implement but we'll be using a lot more IO to send the payload over and over again (but at least it wouldn't sit in the RS's memory).
>  - Send a message alongside a successful put or delete to tell the client to slow down a little, this way we don't have to do back and forth with the payload between the client and the server. It's a cleaner (I think) but more involved solution.
> In every case the RS should do very obvious things to notify the operators of this situation, through logs, web UI, metrics, etc.
> Other ideas?

--
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