Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 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
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.
> > > >
> > > > From my phone
> > > > On Apr 15, 2012 11:20 PM, "Ishaaq Chandy" <[EMAIL PROTECTED]> 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.
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB