Apache River is dying from lack of updates.  While JINI seems like a good
idea here, not sure tying to a project which hasn't moved since 2008 is a
good idea for a contribution to Zookeeeper.  Would love to hear otherwise,
but this has been my experieince with JINI and River.


On Fri, Mar 19, 2010 at 3:52 PM, Patrick Hunt <ph...@apache.org> wrote:

> Hi Brian, sounds like a cool project. While I'm not super familiar with
> Apache River or Jini I do think what you are describing could be beneficial.
> I saw the following recently, is what you are describing a possible solution
> for this situation? http://bit.ly/dabIev
> Historically specifying the ZK server host/port list for client
> applications (zookeeper client sessions) has been an issue for some users.
> If we could provide an option that used River to discover this I believe it
> would be useful.
> We'd be happy to work with you to get something into our contrib module. We
> recently did ivy integration for BookKeeper contrib so there's prior art
> here, we just need to duplicate and change the dependencies. I'd help you
> with this.
> Feel free to open a JIRA and submit a patch to get started:
> https://issues.apache.org/jira/browse/ZOOKEEPER
> http://wiki.apache.org/hadoop/ZooKeeper/HowToContribute
> Regards,
> Patrick
> Brian Murphy wrote:
>> I've recently been assigned to a project using
>> ZooKeeper and so I'm just a (new) user of ZooKeeper,
>> rather than someone interested in making changes to
>> anything internal to ZooKeeper. With that in mind, I'm not
>> sure if this is the right list for the question I have. If it's not,
>> then please forgive the interruption; and I hope someone
>> will (gently) point me to the correct list to pose the
>> question.
>> So here's the context to the question I'd like to ask:
>> The project I've been assigned to would like to be able
>> to do the following with respect to ZooKeeper:
>>  - dynamically discover each peer in an ensemble
>>  - as part of the dynamic discovery of a given peer,
>>   advertise the peer's configuration; in particular, the
>>   clientPort, and the peer and election ports and
>>   peer address
>>  - administratively shutdown (in a graceful fashion) a
>>   given peer
>> To achieve this we've wrapped QuorumPeerMain
>> and ZooKeeperServerMain in an apache river
>> based backend impl class that registers a frontend
>> proxy with a river service directory, from which that
>> proxy (and associated configuration info attribute)
>> can be dynamically discovered.
>> None of the work above requires any changes to
>> the existing ZooKeeper codebase; merely the addition
>> of a handful of classes that can be used or ignored.
>> The question I have then, is whether anyone in the
>> ZooKeeper community would be interested in this work
>> being contributed. If not, no problem. Since the classes
>> above currently do what we want, we'll simply move
>> those new classes into our project's namespace, link
>> to ZooKeeper in the normal way, and go from there.
>> So before we spend any time on trying to figure out how
>> to use ivy to retrieve the appropriate river jars (which we
>> may need help with) or creating example apps & configs
>> to help others to understand and try out this functionality,
>> we thought we'd first try to determine if there's even any
>> interest; and, if there is, then engage the community in
>> how to proceed.
>> Anyway, if there's any interest, please let us know.
>> Regards,
>> Brian

Reply via email to