Mailing-List: contact user-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@hbase.apache.org
Received-SPF: pass (nike.apache.org: domain of dean.hiller@broadridge.com
 designates 64.18.2.22 as permitted sender)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01CBD6AC.42BA405D"
Subject: asynch api mailing list?
Date: Sun, 27 Feb 2011 11:29:23 -0700
Message-ID: 
 <7CA0D5FE7FA83048893E9230C1E9C0280C444C68@DNVREMSA01.jsq.bsg.ad.adp.com>
Thread-Topic: asynch api mailing list?
Thread-Index: AcvWrEGetmcx6ncVTJiJTrvXvyVnJg==
From: "Hiller, Dean  (Contractor)" <dean.hiller@broadridge.com>
To: <hbase-user@hadoop.apache.org>

------_=_NextPart_001_01CBD6AC.42BA405D
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

I had a question on the hbase asynch api.

=20

I find it odd that there is a PleaseThrottleException as on most asynch
systems I have worked on, each node has a queue and when the queue fills
up, the nic buffer in it fills up which means the remote nic buffer then
fills up and then the client should be blocking all writes which means
his incoming buffer fills up, etc. etc. (or he can spin needlessly but
that is usually a very very bad choice...in fact, I have never seen that
work out well and always was reverted).

=20

The nice thing I always found with asynch systems is you completely
control your memory footprint of the server with the incoming
queue...direct relationship between that queue size and the memory of
the node used.  The other things that was always done was asynch reads
but always do synch writes(or block on a lock if write can't go through
until it can go through to slow down the upstream system and throttle
it).....ie. it is a self throttling system when done this way so there
is no need for a PleaseThrottleException which I find odd.

=20

Maybe I am missing something though????  As a client, I definitely want
async reads but my writes should only return if there was room in the
nic buffer to write it out, otherwise it should block and hold up my
client so my client doesn't have to do any extra coding for a
PleaseThrottleException.

=20

In this solution, most of my writes will be asynch right up until hbase
starts becoming a bottleneck.

=20

Thanks,

Dean

=20

=20


This message and any attachments are intended only for the use of the add=
ressee and
may contain information that is privileged and confidential. If the reade=
r of the =

message is not the intended recipient or an authorized representative of =
the
intended recipient, you are hereby notified that any dissemination of thi=
s
communication is strictly prohibited. If you have received this communica=
tion in
error, please notify us immediately by e-mail and delete the message and =
any
attachments from your system.
=0D
------_=_NextPart_001_01CBD6AC.42BA405D--