I've looked at netty too, but I thought Grizzly was a little more mature and I liked the abstractions of Grizzly better.
I'm really looking into something like this for a proof of concept I'm doing that might involve Riak in a very large-scale, massively-concurrent system that handles large transfers of data. The "competition" POCs include Node.js and maybe Ruby/EventMachine. The point is to see if using Java (and/or Scala) in a hugely-scalable, highly-concurrent system can compete with Node.js and others that seem to have more momentum in that area. I'm convinced it can not only compete, but surpass those other platforms considering you have all the benefits of running on the JVM, including management/monitoring and ease of extension through plugins and other extension points. If Riak was to be the data store of record for this system, then I would absolutely need a highly-concurrent, non-blocking driver to access the data from the REST interface, which will be Grizzy HTTP and also non-blocking. I'm going to clean things up a little (I've only implemented get and put but not using the abstractions in the official driver). I think I'm going to refactor that a little and then I'll put it on github and let everyone know. Thanks! Jon Brisbin http//jbrisbin.com ----- Original Message ----- > From: "Mark Wolfe" <m...@wolfe.id.au> > To: "riak-users Users" <riak-users@lists.basho.com> > Sent: Wednesday, June 22, 2011 3:15:09 AM > Subject: Re: Riak async PB client based on Grizzly > I have been interested in doing the same thing for a while. > Instead of Grizzly I started messing around with Netty > https://github.com/netty/ which is very similar. > I am not sure what either of you have found but in my experiance the > NIO stuff only really comes into it's own with large transfers or > routines which rely upon interaction with disk and network IO. For > normal small transaction rates it really doesn't add a lot aside > from being a easier to manage timeouts ect. > If you do start up a project I would be happy to put in some hours > hacking. > Either way best of luck! > On Wed, Jun 22, 2011 at 5:27 PM, Russell Brown < russell.br...@me.com > > wrote: > > Hey Jon, > > > Any chance you want to implement the RawClient interface ( > > https://github.com/basho/riak-java-client/blob/master/src/main/java/com/basho/riak/client/raw/RawClient.java > > ) from the basho riak-java-client library? That way your client can > > be swapped straight into the basho lib? > > > If not, let me know when you get a repo up on github and I'll write > > an adapter so that the basho riak-java-client can make use of your > > Grizzly client, which I guess means I'll pitch in a little (time > > permitting) to help shape the Grizzly client so it is RawClient > > shaped. > > > Cheers > > > Russell > > > On 21 Jun 2011, at 17:58, Jon Brisbin wrote: > > > > I'm trying to get my feet wet with Grizzly on another project, so > > > I've been spending some late(ish) nights also working on a > > > Grizzly-based asynchronous PB client for Riak. I'm dropping all > > > the > > > way down to the protobuf level and using Grizzly's NIO > > > abstractions > > > to implement a completely non-blocking client. I'm writing the > > > low-level stuff in Java and I'd really like to build a Scala > > > layer > > > on top of this, which uses the nice Scala idioms (operators, case > > > classes, etc...). But I can't write code as fast in Scala as I > > > can > > > in Java and some of the Java APIs inside Grizzly aren't all that > > > Scala-friendly and make the code pretty ugly. I figured it would > > > be > > > better to implement a fairly low-level PB client in Java and > > > flesh > > > out the user-facing API in Scala and/or Java. > > > > > > My question is basically, if I seed this project on GitHub with > > > what > > > I've got so far, would anyone else be interested in helping > > > complete > > > it? I'm just working on this after my other Grizzly work, so I > > > can't > > > devote full time to it. It might take me a little while to > > > implement > > > things like links and mapreduce. > > > > > > I think it shows some real promise because it is completely > > > non-blocking. It uses Futures and CompletionHandlers to do the > > > dirty > > > work. A Grizzly filter is responsible for the actual > > > encoding/decoding of protobuf data. Right now, it will marshall > > > JSON > > > using Jackson if your content-type is set to "application/json", > > > otherwise it uses JDK serialization to encode the entry (or just > > > passes a String straight through, of course). > > > > > > Since it's a first pass, there is no real attempt to separate the > > > protobuf stuff from the client. That's a v2 thing. Since I have > > > limited time, I'm interested in speed to completion of features > > > rather than good-looking and properly abstracted code. :) > > > > > > Thanks! > > > > > > Jon Brisbin > > > > > > http// jbrisbin.com > > > > > > _______________________________________________ > > > > > > riak-users mailing list > > > > > > riak-users@lists.basho.com > > > > > > http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com > > > > > _______________________________________________ > > > riak-users mailing list > > > riak-users@lists.basho.com > > > http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com > > -- > Regards, > Mark Wolfe > -- > I am not young enough to know everything. > -- > _______________________________________________ > riak-users mailing list > riak-users@lists.basho.com > http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
_______________________________________________ riak-users mailing list riak-users@lists.basho.com http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
