Mailing-List: contact hbase-dev-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: hbase-dev@hadoop.apache.org
Received-SPF: pass (nike.apache.org: domain of saint.ack@gmail.com designates
 209.85.132.249 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:sender:in-reply-to:references:date
         :x-google-sender-auth:message-id:subject:from:to:content-type;
        b=LdOLLR/imcjJjJBxPqM4Vkb1AF+8pQIIRiBhaV5CDbkGuDZpJVLFbnaetd4u3TGwPi
         fLg17pn1EWvKtXdMPeEuGLi6fB7zY170Lv1CJE74KOGcpq4eEzwr/mdd2UZ3d9sm/u8B
         elTLy7MoIZTiF93grGfrFb34ZFfoMfAShZy9I=
MIME-Version: 1.0
Sender: saint.ack@gmail.com
In-Reply-To: <91397.89414.qm@web65509.mail.ac4.yahoo.com>
References: <853272.19024.qm@web65513.mail.ac4.yahoo.com>
	 <91397.89414.qm@web65509.mail.ac4.yahoo.com>
Date: Sat, 7 Feb 2009 12:36:00 -0800
Message-ID: <7c962aed0902071236r5da2563eve651b826eff080d4@mail.gmail.com>
Subject: Re: HADOOP-3856
From: stack <stack@duboce.net>
To: hbase-dev@hadoop.apache.org, apurtell@apache.org
Content-Type: multipart/alternative; boundary=0016e64615b0dc132404625a15d4

--0016e64615b0dc132404625a15d4
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Did you see in the hadoop issue where Raghu talks of grizzly mayhaps been
better suited because it has more accomodating community and its written
more to the datanode level?

Would suggest keeping Raghu in the loop.  Perhaps by posting intermediary
patches up against the hadoop issue.

I can help pre-review patches and with testing.

You are a good man Andrew Purtell.
St.Ack

On Fri, Feb 6, 2009 at 11:00 AM, Andrew Purtell <apurtell@apache.org> wrote:

> So it looks like a complete rewrite of the datanode network I/O
> in the async model is necessary. I don't want to invest the time
> if in the end it isn't enough to significantly affect HBase
> stability in a positive way.
>
> Blocking in disk I/O will be out of scope.
>
>   - Andy
>
>
> > From: Andrew Purtell
> >
> > I have started work on this. The plan is to use selectable
> > channels (set to blocking mode), a work queue, and a pool of
> > worker threads to handle xceiver connections.
> [...]
> > However, it may be necessary to go fully async
> [...]
>
>
>
>
>

--0016e64615b0dc132404625a15d4--