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
