Thanks to Oleg from the Grizzly users mailing list, the problem with the protobuf handling code now seems fixed. The non-blocking, Grizzly (and thus NIO) based Java client I'm experimenting with seems to work quite well.
https://github.com/jbrisbin/riak-async-java-client It doesn't do link walking or map/reduce yet just because I haven't had time to implement those features. I'm more interested in the asynchronous API portion at the moment. I'm curious whether a Future-based approach or a callback-based approach will be better in the long run. Until such time as Java has closures, I think the callback-based approach will work better with other NIO and non-blocking frameworks. Most of those have a CompletionHandler abstraction which would fit very well with the callback style. But user application code might want to rely on the Future style in some places (like integrating with blocking code in other parts of the app). The client implements a modified form of Russell's RawClient and uses the abstractions from the new Java client to make it very compatible with the regular, blocking Java client. The RawAsyncClient has both Future and callback operations in the same interface. I'd rather split these up into two separate interfaces and give a convenience method on the RiakAsyncClient object to get either of the interfaces so you can work only with Futures or only with callbacks. This will dramatically reduce the noise in your IDE as your working, as you won't see all those overrides in a single list. The basic use case is in a Grizzly web app where I need fully-non-blocking IO to all components in the app. 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
