zookeeper-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ted Dunning <ted.dunn...@gmail.com>
Subject Re: Input on a change
Date Mon, 16 Apr 2012 19:53:40 GMT
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 <camille@apache.org>

> 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 <scottfines@gmail.com>
>
> > 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 <john.sirois@gmail.com>
> > wrote:
> >
> > > On Mon, Apr 16, 2012 at 10:52 AM, Ishaaq Chandy <ishaaq@gmail.com>
> > 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 <camille@apache.org> 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.
> > > > >
> > > > > From my phone
> > > > > On Apr 15, 2012 11:20 PM, "Ishaaq Chandy" <ishaaq@gmail.com>
> wrote:
> > > > >
> > > > > > I'd go so far as to say that even the server-code should avoid
> > > > > System.exit.
> > > > > > Just because it is "meant" to be a standalone system doesn't
mean
> > > that
> > > > > code
> > > > > > that makes it impossible to embed it should be encouraged.
> > > > > >
> > > > > > For e.g, we embed a local version of ZK to be used inside our
> unit
> > > > tests.
> > > > > > This makes it much easier for us to control ZK to coincide with
> > test
> > > > > > expectations as well as making for much faster build times.
It
> > would
> > > > be a
> > > > > > shame if the embedded ZK started killing the JVM.
> > > > > >
> > > > > > Ishaaq
> > > > > >
> > > > > > On 16 April 2012 04:28, Camille Fournier <camille@apache.org>
> > wrote:
> > > > > >
> > > > > > > This is a good point.
> > > > > > > I think this change should be fine for the server portion
of
> the
> > > > code,
> > > > > > > since it's designed to be run as a standalone system. But
for
> the
> > > > > > > client connection to also call system.exit on such an error
is
> > > > > > > overreaching for all the reasons listed below.
> > > > > > >
> > > > > > > C
> > > > > > >
> > > > > > > 2012/4/15 Віталій Тимчишин <tivv00@gmail.com>:
> > > > > > > > I really would not like for any library to perform
a
> > System.exit
> > > > > call.
> > > > > > > This
> > > > > > > > would make huge program exit out of sudden (think
about j2ee,
> > you
> > > > may
> > > > > > be
> > > > > > > > bitten by security manager).  Note that there are
more or
> less
> > > safe
> > > > > > > errors,
> > > > > > > > like StackOverflowError.
> > > > > > > > Also System.exit make testing nightmare. E.g. maven2
silently
> > > skips
> > > > > any
> > > > > > > > tests after the one that calls System.exit. And everything's
> > > green.
> > > > > > > > As for me good options are:
> > > > > > > > 1) Call user-provided uncaught exception handler.
Use the one
> > > from
> > > > > the
> > > > > > > > thread that created the connection if one is not specified
> > > > explicity.
> > > > > > > > 1) Stop everything, notifying user with a global watcher.
If
> > it's
> > > > > > > possible,
> > > > > > > > clean any static state (e.g. restart threads) and
allow to
> > > restart
> > > > > > > > connection.
> > > > > > > > In any case, call user code. Good system already know
how to
> > > react
> > > > > (it
> > > > > > > may
> > > > > > > > want to send email to admin), allow it to perform
well.
> > > > > > > >
> > > > > > > > Best regards, Vitalii Tymchyshyn.
> > > > > > > >
> > > > > > > > 2012/4/13 Camille Fournier <camille@apache.org>
> > > > > > > >
> > > > > > > >> Hi everyone,
> > > > > > > >>
> > > > > > > >> I'm trying to evaluate a patch that Jeremy Stribling
has
> > > > submitted,
> > > > > > and
> > > > > > > I'd
> > > > > > > >> like some feedback from the user base on it.
> > > > > > > >> https://issues.apache.org/jira/browse/ZOOKEEPER-1442
> > > > > > > >>
> > > > > > > >> The current behavior of ZK when we get an uncaught
exception
> > is
> > > to
> > > > > log
> > > > > > > it
> > > > > > > >> and try to move on. This is arguably not the right
thing to
> > do,
> > > > and
> > > > > > will
> > > > > > > >> possibly cause ZK to limp along with a bad VM
(say, in an
> OOM
> > > > state)
> > > > > > for
> > > > > > > >> longer than it should.
> > > > > > > >> The patch proposes that when we get an instance
of
> > > > java.lang.Error,
> > > > > we
> > > > > > > >> should do a system.exit to fast-fail the process.
With the
> > > > possible
> > > > > > > >> exception of ThreadDeath (which may or may not
be an
> > > unrecoverable
> > > > > > > system
> > > > > > > >> state depending on the thread), I think this makes
sense,
> but
> > I
> > > > > would
> > > > > > > like
> > > > > > > >> to hear from others if they have an opinion. I
think it's
> > better
> > > > to
> > > > > > kill
> > > > > > > >> the process and let your monitoring services detect
process
> > > death
> > > > > (and
> > > > > > > thus
> > > > > > > >> restart) than possibly linger unresponsive for
a while, are
> > > there
> > > > > > > scenarios
> > > > > > > >> that we're missing where this error can occur
and you
> wouldn't
> > > > want
> > > > > > the
> > > > > > > >> process killed?
> > > > > > > >>
> > > > > > > >> Thanks for your feedback,
> > > > > > > >>
> > > > > > > >> Camille
> > > > > > > >>
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > --
> > > > > > > > Best regards,
> > > > > > > >  Vitalii Tymchyshyn
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message