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.
Jonathan 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 >> >>