Voldemort Fun Project Ideas

[Rajiv Nair]

Hi, 

I am interested in Voldemort and am looking to make some contributions. I thought that a client in node.js would be a good place to start and was wondering if anyone was already working on this? 

Thanks,

rsnair

[Felix GV]

I don't think anyone's working on this at the moment.

Are you looking to make this client non-blocking?

As far as I know, there is no first-class support for "non-blocking-ness" on the Voldemort server side, but you could implement that on the client side, I imagine.

Also worth noting: the Coordinator project (in contribs) would make it easier to develop thin clients in new languages as it exposes a REST API. Since it's just REST, it may also make it easy to coerce into an off-the-shelf non-blocking HTTP client. Coordinator and the thin client do work but they have not been tested extensively in production environments yet, so their performance characteristics in high-throughput haven't been certified thoroughly yet.

--
 
Felix GV
Data Infrastructure Engineer
Distributed Data Systems
LinkedIn
 
f...@linkedin.com
linkedin.com/in/felixgv

---

From: project-...@googlegroups.com [project-...@googlegroups.com] on behalf of Rajiv Nair [rajiv....@gmail.com]
Sent: Saturday, December 20, 2014 2:32 PM
To: project-...@googlegroups.com
Subject: [project-voldemort] Voldemort Fun Project Ideas

--
You received this message because you are subscribed to the Google Groups "project-voldemort" group.
To unsubscribe from this group and stop receiving emails from it, send an email to project-voldem...@googlegroups.com.
Visit this group at http://groups.google.com/group/project-voldemort.
For more options, visit https://groups.google.com/d/optout.

[Rajiv Nair]

Hey Felix, 

Thanks for getting back to me. I have completed a first functional prototype, though there is still some stuff left. The link to the Github repo is: https://github.com/rsnair2/Voldemort-Client-Node. 

I designed it to make use of Javascript's event driven persona and so none of the calls block. Furthermore, the client can reduce I/O waiting times by performing requests concurrently over multiple sockets - the client maintains a set of connections with nodes in the cluster (after bootstrapping). There is also an atomic wrapper that makes some guarantees on the ordering of get/delete/put requests so that the client does not return stale values or mix up the ordering of writes (put/delete) as that can affect correctness. Currently, the client is not using the HTTP socket and protocol, but it can be modified to take advantage of it. A future update perhaps?

I will update you when I am done, but for now I just have to do some book-keeping stuff like packaging it, improving error handling and writing some unit tests. I would love to get your thoughts/suggestions on this though. 

Regards, 

Rajiv

[Felix GV]

Hi Rajiv,

It's great that you're contributing your work back to the open-source community (: !

Unfortunately, I would make a very poor reviewer since I have very little experience with JS and none with Node.

Maybe someone else on the list can take a look.

--
 
Felix GV
Data Infrastructure Engineer
Distributed Data Systems
LinkedIn
 
f...@linkedin.com
linkedin.com/in/felixgv

From: project-...@googlegroups.com [project-...@googlegroups.com] on behalf of Rajiv Nair [rajiv....@gmail.com]

Sent: Thursday, January 08, 2015 12:37 PM
To: project-...@googlegroups.com
Subject: Re: [project-voldemort] Voldemort Fun Project Ideas

[Chinmay Soman]

FYI: Rajiv - are you pointing the JS client to the coordinator ? 

Or have you implemented the full fledged thick client in JS ?

[Rajiv Nair]

To be clear, the coordinator is any node within the cluster that is in charge of routing correct? In that case, I have pointed the JS client to a coordinator (from my understanding this entails that the should_route variable in the query should be true). Would it be preferable to have the client perform the routing itself?