[
https://issues.apache.org/jira/browse/ZOOKEEPER-505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12741044#action_12741044
]
Flavio Paiva Junqueira commented on ZOOKEEPER-505:
--------------------------------------------------
Great catch, Utkarsh! I noticed this problem a while ago in the ReadWrite tests
and fixed by changing the catch blocks to the following:
{noformat}
catch (BKException e) {
LOG.error("Test failed", e);
fail("Test failed due to BookKeeper exception");
}
{noformat}
Clearly we forgot to implement the change in all places. Also, we shouldn't
have calls to printStackTrace. Now I wonder if it is best to remove the catch
block as you propose or to catch and fail as I propose above. I don't know the
exact semantics of junit with respect to exceptions, but recently I've seen a
case that a test was throwing an exception and not catching it, and was still
passing.
> testAsyncCreateClose is badly broken
> ------------------------------------
>
> Key: ZOOKEEPER-505
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-505
> Project: Zookeeper
> Issue Type: Bug
> Components: contrib-bookkeeper
> Reporter: Utkarsh Srivastava
> Priority: Critical
> Attachments: ZOOKEEPER-505.1.patch
>
>
> The test case testAsyncCreateClose is badly broken. I was wondering why all
> the unit tests are passing inspite of having found so many different problems
> with LedgerManagementProcessor.
> There is a big try-catch block sitting in the test case that catches all
> exception, prints their stack trace, and exits, thereby allowing the test to
> pass. In general, unit tests shouldnt catch exceptions unless it is something
> you are expecting that will happen.
> Another problem is that the same ControlObject is used for synchronization
> throughout. Since we already have the problem of callbacks being called
> multiple times (ZOOKEEPER-502), notify() on the control object is called too
> many times, resulting in the unit test not waiting for certain callbacks.
> Thus the test never waits for the asyncOpenLedger() to finish, and hence
> still succeeds. I believe asyncOpenLedger() has never worked right.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
