You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@uima.apache.org by "Jerry Cwiklik (JIRA)" <de...@uima.apache.org> on 2017/08/23 20:09:00 UTC

[jira] [Updated] (UIMA-5539) UIMA-DUCC: review and fix code where Throwable is caught

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

Jerry Cwiklik updated UIMA-5539:
--------------------------------
    Description: 
Catching Throwable which includes both java Error and Exception is not a good practice. If a java error is thrown, say OOM, the application code should let the jvm handle it. 

In one concrete instance, the JD was experiencing an OOM due to a faulty user CR. Instead of trying to send CASes by reference it was trying to pass them by value. The OOM was caught and immediately wrapped in RuntimeException and subsequently rethrown. The jvm did not have a chance to catch the OOM leaving JD process running and eventually it hung with multiple JPs in limbo.

Review all ducc code where we catch Throwable and determine if this can be changed to catching Exceptions, letting the jvm handle the Errors. Optionally, ducc can plug in an UncaughtErrorHandler to the java main thread where we can decide what to do with each error that is caught. I think all java Errors should cause the jvm to exit immediately via halt().

Since Ducc daemons, JPs, JDs, etc use other frameworks like Spring, ActiveMQ, Jetty we should test what happens if Throwables are not caught in ducc code. Hopefully these frameworks dont catch Throwables and allow them to float up to be caught by java or custom UncaughtErrorHandler.

  was:
Catching Throwable which includes both java Error and Exception is not a good practice. If a java error is thrown, say OOM, the application code should let the jvm handle it. 

In one concrete instance, the JD was experiencing an OOM due to a faulty user CR. Instead of trying to send CASes by reference it was trying to pass them by value. The OOM was caught and immediately wrapped in RuntimeException and subsequently rethrown. The jvm did not have a chance to catch the OOM leaving JD process running and eventually it hung with multiple JPs in limbo.

Review all ducc code where we catch Throwable and determine if this can be changed to catching Exceptions, letting the jvm handle the Errors. Optionally, ducc can plug in an UncaughtErrorHandler to the java main thread where we can decide what to do with each error that is caught. I think all java Errors should cause the jvm to exit immediately via halt().

Since Ducc daemons, JPs, JDs, etc use other frameworks like Spring, ActiveMQ, Jetty we should test what happens if Throwables are not caught in ducc code. Hopefully these frameworks dont caught Throwables and allow them to float up to be caught by java or custom UncaughtErrorHandler.


> UIMA-DUCC: review and fix code where Throwable is caught 
> ---------------------------------------------------------
>
>                 Key: UIMA-5539
>                 URL: https://issues.apache.org/jira/browse/UIMA-5539
>             Project: UIMA
>          Issue Type: Bug
>          Components: DUCC
>            Reporter: Jerry Cwiklik
>            Assignee: Jerry Cwiklik
>             Fix For: future-DUCC
>
>
> Catching Throwable which includes both java Error and Exception is not a good practice. If a java error is thrown, say OOM, the application code should let the jvm handle it. 
> In one concrete instance, the JD was experiencing an OOM due to a faulty user CR. Instead of trying to send CASes by reference it was trying to pass them by value. The OOM was caught and immediately wrapped in RuntimeException and subsequently rethrown. The jvm did not have a chance to catch the OOM leaving JD process running and eventually it hung with multiple JPs in limbo.
> Review all ducc code where we catch Throwable and determine if this can be changed to catching Exceptions, letting the jvm handle the Errors. Optionally, ducc can plug in an UncaughtErrorHandler to the java main thread where we can decide what to do with each error that is caught. I think all java Errors should cause the jvm to exit immediately via halt().
> Since Ducc daemons, JPs, JDs, etc use other frameworks like Spring, ActiveMQ, Jetty we should test what happens if Throwables are not caught in ducc code. Hopefully these frameworks dont catch Throwables and allow them to float up to be caught by java or custom UncaughtErrorHandler.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)