kafka-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ismael Juma (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (KAFKA-4039) Exit Strategy: using exceptions instead of inline invocation of exit/halt
Date Sat, 17 Sep 2016 07:56:20 GMT

     [ https://issues.apache.org/jira/browse/KAFKA-4039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Ismael Juma updated KAFKA-4039:
    Priority: Critical  (was: Major)

> Exit Strategy: using exceptions instead of inline invocation of exit/halt
> -------------------------------------------------------------------------
>                 Key: KAFKA-4039
>                 URL: https://issues.apache.org/jira/browse/KAFKA-4039
>             Project: Kafka
>          Issue Type: Bug
>          Components: core
>    Affects Versions:
>            Reporter: Maysam Yabandeh
>            Priority: Critical
>             Fix For:
>         Attachments: deadlock-stack2
> The current practice is to directly invoke halt/exit right after the line that intends
to terminate the execution. In the case of System.exit this could cause deadlocks if the thread
invoking System.exit is holding  a lock that will be requested by the shutdown hook threads
that will be started by System.exit. An example is reported by [~aozeritsky] in KAFKA-3924.
This would also makes testing more difficult as it would require mocking static methods of
System and Runtime classes, which is not natively supported in Java.
> One alternative suggested [here|https://issues.apache.org/jira/browse/KAFKA-3924?focusedCommentId=15420269&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15420269]
would be to throw some dedicated exceptions that will eventually invoke exit/halt:
> {quote} it would be great to move away from executing `System.exit` inline in favour
of throwing an exception (two examples, but maybe we can find better names: FatalExitException
and FatalHaltException) that is caught by some central code that then does the `System.exit`
or `Runtime.getRuntime.halt`. This helps in a couple of ways:
> (1) Avoids issues with locks being held as in this issue
> (2) It makes it possible to abstract the action, which is very useful in tests. At the
moment, we can't easily test for these conditions as they cause the whole test harness to
exit. Worse, these conditions are sometimes triggered in the tests and it's unclear why.
> (3) We can have more consistent logging around these actions and possibly extended logging
for tests
> {quote}

This message was sent by Atlassian JIRA

View raw message