On Mon, Apr 16, 2012 at 10:52 AM, Ishaaq Chandy 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
Sure, mocking it's a helluva lot faster too.
C
>From my phone
On Apr 16, 2012 12:54 PM, "Ishaaq Chandy" 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. Quic
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 bu
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" wrote:
> I'd go so far as to say that even
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. mav
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
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 Віталій Тимчишин
gt;
>>>http://docs.oracle.com/javase/6/docs/api/java/lang/Thread.UncaughtExcept
>>>ionHandler.html#uncaughtException%28java.lang.Thread,%20java.lang.Throwa
>>>ble%29
>>>
>>> " Any exception thrown by this method will be ignored by the Java
>>>Virtual
>&
gt; Machine."
>>
>>
>>> --Michi
>>>
>>> From: Scott Fines [scottfi...@gmail.com]
>>> Sent: Friday, April 13, 2012 8:15 AM
>>> To: u...@zookeeper.apache.org
>>> Cc: zookeeper-u...@hadoo
y exception thrown by this method will be ignored by the Java Virtual
> Machine."
>
>
>> --Michi
>>
>> From: Scott Fines [scottfi...@gmail.com]
>> Sent: Friday, April 13, 2012 8:15 AM
>> To: u...@zookeeper.apache.org
>> Cc: zookeeper-u...@h
r-u...@hadoop.apache.org; zookeeper-...@hadoop.apache.org
Subject: Re: Input on a change
On some JVMs (the HotSpot for sure, but maybe others too?) there's a JVM
for performing actions on OutOfMemoryErrors (-XX:OnOutOfMemoryError=", -XX:+HeapDumpOnOutOfMemoryError and maybe some others that I can&#
n use flags like -XX:+HeapDumpOnOutOfMemoryError.
--Michi
From: Scott Fines [scottfi...@gmail.com]
Sent: Friday, April 13, 2012 8:15 AM
To: u...@zookeeper.apache.org
Cc: zookeeper-u...@hadoop.apache.org; zookeeper-...@hadoop.apache.org
Subject: Re: Input on a change
On some J
And to go just a bit further with this, would this be considered a
non-backward compatible change to the core expectations of the system
(even if it's patching a "bug")? It changes the "expected" behavior of the
application from an undefined possible zombie state to fail-fast.
Theoretically, that m
Just my 2 centsŠ is the error code 1 the correct error code to return to
the OS? I'm just curious if anywhere else in ZooKeeper a System.exit(1)
may be called. It may make sense to either re-use that error code, or use
a different one (if 1 is already used elsewhere for a different type of
error, l
On some JVMs (the HotSpot for sure, but maybe others too?) there's a JVM
for performing actions on OutOfMemoryErrors (-XX:OnOutOfMemoryError=", -XX:+HeapDumpOnOutOfMemoryError and maybe some others that I can't
remember off the top of my head). Will these triggers still be fired, or
will the catch-
15 matches
Mail list logo
