Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
Zookeeper, mail # user - Re: Input on a change


Copy link to this message
-
Re: Input on a change
Ted Dunning 2012-04-16, 19:53
It would be lovely to have a ZK test jar that facilitates mock testing like
this.  I have done as Camille has, but the result is that we have probably
replicated work without resulting in a usable framework.

Shame on me at least.

The mockup structure for tests *inside* ZK is far better than the structure
available outside of ZK.  Unfortunately, every time I have taken a run at
this, it has exceeded my fun-time budget without significant publishable
results.

2012/4/16 Camille Fournier <[EMAIL PROTECTED]>

> I've done extensive ZK client testing mostly using mocks with great
> success. I agree that there's cases when embedding a ZK is probably the
> easiest way to go, but it is actually much easier to simulate most failure
> cases in ZK via mocks than running an embedded server. It does require more
> up-front developer thought to set up the tests, but that thought pays
> dividends in that you actually are then forced to understand the possible
> failures and simulate them.
> It seems ultimately like a flag is the right way to go here, so I'll leave
> that feedback on the ticket.
>
> C
>
> 2012/4/16 Scott Fines <[EMAIL PROTECTED]>
>
> > Not to start a flame war here..
> >
> > Mocks are good for a lot of purposes, but I can think of a few cases
> where
> > testing failure states is a lot easier if you are actively contacting a
> ZK
> > server (like testing a failed client connection's consequences). To that
> > end, it seems like a good idea to support this kind of testing. So far,
> the
> > easiest way seems to be embedding a ZK Server.
> >
> > On the other hand, it doesn't seem likely that an active, production ZK
> > cluster is going to want any kind of unusual behavior. It's almost always
> > better to have some kind of behavior that is very well defined and
> > predictable happen, even if that behavior is catastrophic. In this case,
> > having a production server shut itself off whenever it doesn't know how
> to
> > recover is very predictable, and can be designed around. Leaving that
> > cluster in an awkward state that may or may not behave predictably is
> much
> > harder to work with.
> >
> > I personally can't see much else that you'd want to do in this scenario
> > that falls far enough outside these two patterns that it's worth
> supporting
> > custom handlers. It seems like the support time would be better spent
> > developing and planning around these two states.
> >
> > Scott
> >
> >
> >
> > On Mon, Apr 16, 2012 at 1:09 PM, John Sirois <[EMAIL PROTECTED]>
> > wrote:
> >
> > > On Mon, Apr 16, 2012 at 10:52 AM, Ishaaq Chandy <[EMAIL PROTECTED]>
> > wrote:
> > >
> > > > Fair enough, if you think it is an anti-pattern then perhaps you can
> > > > suggest an alternative that allows one to write tests that are (in
> > > > descending order of priority):
> > > >
> > > > 1. Quick and easy to setup and teardown
> > > > 2. Repeatably testable and debuggable in an IDE without having to
> > resort
> > > to
> > > > the external build tool
> > > > 3. Testable in parallel, i.e. having more than one build running on a
> > CI
> > > > server, so need some way to avoid port clashes
> > > > 4. Cross-platform - i.e. run the exact same build sequence on
> multiple
> > > > OSes.
> > > >
> > >
> > > We also embed for testing for all the reasons above with good success.
> >  In
> > > fact - I like the idea of the server product directly supporting
> > alternate
> > > mains - although this may be more burden on zk devs initially.  This
> > would
> > > allow an org to write their own main that plugs in an uncaught handler
> > and
> > > does whatever is appropriate in their deploy environment.
> > >
> > >
> > > >
> > > > Ishaaq
> > > >
> > > > On 16 April 2012 22:55, Camille Fournier <[EMAIL PROTECTED]> wrote:
> > > >
> > > > > I believe that this change is inspired by someone that runs zk
> > > embedded.
> > > > > Personally I'm not moved by the testing argument, embedding the
> > server
> > > > for
> > > > > testing is a bit of an anti pattern in my mind.