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
I would be very happy with a solution that allows a custom uncaught
exception handler -- that's how we are working around this issue now, by
installing a new default uncaught exception handler after we're sure
NIOServerCnxnFactory has installed its own.  I do think by default ZK
should shut down predictably if it hits an error (with the possible
exception of ThreadDeath), but turning it off by default until a major
release seems reasonable if we allow a custom handler.

I don't know that I'm the right person to implement it though, not being
super strong in Java or in the design of user inputs into ZK, so if
anyone wants to take a crack at this, feel free.

On 04/16/2012 11:27 AM, Scott Fines wrote:
> 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.