helix-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kanak Biscuitwala <kana...@hotmail.com>
Subject RE: Node.js Helix Participant
Date Mon, 23 Sep 2013 18:33:48 GMT
+1. Jason and I will work on the spec and will point you to it once it's ready.

> Date: Mon, 23 Sep 2013 11:30:23 -0700 
> Subject: Re: Node.js Helix Participant 
> From: g.kishore@gmail.com 
> To: user@helix.incubator.apache.org 
> Hi Kevin, 
> This will be a great addition. We, at LinkedIn are also seeing the need 
> to have Helix Participant in other languages such as Python. Python 
> already has some good zk libraries. I am not sure if we have good zk 
> libraries in node.js/javascript (Patrick, might have some suggestions). 
> I think it will definitely help the community and we are interested in 
> python implementation. 
> The best way to approach this would be to first come up with a minimal 
> spec required for the participant. Currently things that participant 
> does is 
> * Create a ephemeral node under liveinstances when it starts 
> * Listen to messages node for commands from the controller 
> * Update the current state with the result of the command. 
> thanks, 
> Kishore G 
> On Thu, Sep 19, 2013 at 11:24 AM, Kevin Gao 
> <kgao@box.com<mailto:kgao@box.com>> wrote: 
> Hi all, 
> My colleagues at Box and I are considering developing a Node.js based 
> Helix participant library as an open source project. I first and 
> foremost wanted to gauge how useful this would be in the community's 
> use cases. For us, the main service runs on Node.js and is the actual 
> owner of resources, while we treat Helix as the one, shared source of 
> truth regarding which nodes own what resources. This introduces a split 
> brain scenario between the two. In the mean time, we have introduced 
> health checking and state validation to ensure that the two are 
> consistent. Additionally, we have developed a local protocol for 
> communicating state transitions. However, maintaining this architecture 
> leaves room for inconsistency as well as significant slow down in 
> developing actual application logic. 
> What we think would be extremely useful to us is to have write a 
> JavaScript-based participant library. This involves a few major 
> questions to be answered first: 
> * Is the community interested in the availability of this project? 
> * Is there a reliable, vetted ZooKeeper client for Node.js? 
> * What components of the Helix library need to be ported over? 
> * Related to the previous question, what feature set is required at 
> minimum for a production-ready library? 
> * How difficult would it be to maintain this library in parallel to the 
> main Helix distribution? 
> My team and I would appreciate any feedback or input you have! 
> Best, 
> Kevin 
> -- 
> Kevin Gao 
> kgao@box.com<mailto:kgao@box.com> 
View raw message