Adding support for more config options to MiniZooKeeperCluster

[Dave Wang <ds...@cloudera.com>]

Hello,

I wanted to add tickTime and min/max timeout support into
MiniZooKeeperCluster, and have a small patch to do that ready to go.
 However, I was wondering if it makes more sense to make the codepaths for
configuring and starting MiniZooKeeperCluster more like the non-standalone
codepaths through HQuorumPeer, so that more of the codepaths are shared.
 Do folks have a preference one way or the other?

Regards,

- Dave

Re: Adding support for more config options to MiniZooKeeperCluster

[Stack <st...@duboce.net>]

On Thu, Mar 22, 2012 at 10:20 AM, Dave Wang <ds...@cloudera.com> wrote:
> Is it really a requirement for HBase to have and support a synchronous
> shutdown for ZK?  If the answer is "yes", then we may want to change the
> current non-standalone codepath to implement this.  If the answer is "no",
> then we should get rid of the existing code in MiniZooKeeperCluster that
> implements this, which would make it easier to unify the two codepaths.
>

Synchronous shutdown was probably just easier to reason around writing
tests.  That as best as I can remember is only the reason for it (if
there ever was a 'reason').

If doing it async makes it so one code path for all deploy types and
it 'works', go for it.

Thanks boss,
St.Ack

Re: Adding support for more config options to MiniZooKeeperCluster

[Dave Wang <ds...@cloudera.com>]

Stack,

I took a first whack at this.

It's going to be impossible to unify the two configure/start codepaths
exactly, as the standalone HBase path currently requires a synchronous
shutdown() path for the MiniZooKeeperCluster, whereas the non-standalone
path doesn't (it currently just relies on the scripts to kill the zookeeper
processes).  In fact, the non-standalone codepath doesn't have a good way
of having a synchronous shutdown path without some changes.

I noticed that a bunch of unit tests have synchronous shutdown calls, which
is perhaps not surprising considering MiniZooKeeperCluster came from unit
test code.  But this all seems limited to only the standalone HBase case,
and I don't see why this has to be different for the standalone case.

Is it really a requirement for HBase to have and support a synchronous
shutdown for ZK?  If the answer is "yes", then we may want to change the
current non-standalone codepath to implement this.  If the answer is "no",
then we should get rid of the existing code in MiniZooKeeperCluster that
implements this, which would make it easier to unify the two codepaths.

- Dave

On Tue, Mar 20, 2012 at 11:41 AM, Stack <st...@duboce.net> wrote:

> On Mon, Mar 19, 2012 at 3:39 PM, Dave Wang <ds...@cloudera.com> wrote:
> > I wanted to add tickTime and min/max timeout support into
> > MiniZooKeeperCluster, and have a small patch to do that ready to go.
> >  However, I was wondering if it makes more sense to make the codepaths
> for
> > configuring and starting MiniZooKeeperCluster more like the
> non-standalone
> > codepaths through HQuorumPeer, so that more of the codepaths are shared.
>
> I would be up for reviewing and committing a patch that did a bigger
> change whose objective was reducing the number of code paths.
> Thanks David,
> St.Ack
>

Re: Adding support for more config options to MiniZooKeeperCluster

[Stack <st...@duboce.net>]

On Mon, Mar 19, 2012 at 3:39 PM, Dave Wang <ds...@cloudera.com> wrote:
> I wanted to add tickTime and min/max timeout support into
> MiniZooKeeperCluster, and have a small patch to do that ready to go.
>  However, I was wondering if it makes more sense to make the codepaths for
> configuring and starting MiniZooKeeperCluster more like the non-standalone
> codepaths through HQuorumPeer, so that more of the codepaths are shared.

I would be up for reviewing and committing a patch that did a bigger
change whose objective was reducing the number of code paths.
Thanks David,
St.Ack