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 <[email protected]> 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 > [email protected] > http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com > > > > _______________________________________________ > riak-users mailing list > [email protected] > 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 [email protected] http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
