hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From stack <st...@duboce.net>
Subject Re: HADOOP-3856
Date Sun, 08 Feb 2009 22:10:45 GMT
On Sat, Feb 7, 2009 at 2:27 PM, Andrew Purtell <apurtell@apache.org> wrote:

> I'm wondering if any async framework offers enough to make an
> external dependency worthwhile. What benefit do they provide, at
> the low level that the datanode would operate? I'm not sure.



I don't have enough experience to say whether or which.  Reading -- not
implementing -- what I learned about an nio implementation is that its easy
to make a mess; in particular an implementation that works but that is dog
slow or resource expensive.  I got the sense that using one of the
frameworks would help avoid the ready traps.  Then again, I was reading the
framework's literature and did not make a discount for self-promotion.

Regards dependency, if its working the dependency will be overlooked (IMO).

St.Ack

>
> I've used Netty before, but it's LGPL. Grizzly and MINA are two
> more or less equivalent options that I am aware of. MINA is ASF.
> That's probably the least objectionable external dependency, but
> then I go back to the question of how much time savings would it
> offer? There's a learning curve for me in any direction, picking
> apart the DN, piecing it back together. There's no argument
> against a new dependency if I just go with plain NIO.
>
> Is anyone aware of some compelling benefit to Grizzly or MINA or
> some serious pitfall with just using plain NIO? I'm a C++ guy
> still learning the Java landscape here...
>
>   - Andy
>
> > From: stack
> >
> > 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.
>
>
>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message