You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@storm.apache.org by "Jungtaek Lim (JIRA)" <ji...@apache.org> on 2017/08/09 04:46:00 UTC

[jira] [Resolved] (STORM-2028) Exceptions in JDBCClient are hidden by subsequent SQL-Exception in close()

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

Jungtaek Lim resolved STORM-2028.
---------------------------------
       Resolution: Fixed
    Fix Version/s: 2.0.0

Thanks [~CobraCrowe], I merged into master.
Keep up the good work.

> Exceptions in JDBCClient are hidden by subsequent SQL-Exception in close()
> --------------------------------------------------------------------------
>
>                 Key: STORM-2028
>                 URL: https://issues.apache.org/jira/browse/STORM-2028
>             Project: Apache Storm
>          Issue Type: Bug
>          Components: storm-jdbc
>    Affects Versions: 2.0.0
>            Reporter: Rick Moritz
>            Assignee: Rahul Jain
>            Priority: Minor
>              Labels: newbie
>             Fix For: 2.0.0
>
>          Time Spent: 2h 40m
>  Remaining Estimate: 0h
>
> When an Exception is triggered in JdbcClient.executeInsertQuery there is the potential for a follow-up Exception in close() to take precedence over the previously thrown Exception, when triggered in the finally block. This makes debugging the actual Exception impossible.
> As far as I can tell it would be better to catch the Exception form close() in the finally-block, and to combine it with the existing Exception, so that the key information for debugging purposes isn't lost.
> For data consistency purposes we have to make sure that the Exception from closing the connection is thrown (or do we? can we be sure that a successful commit has persisted the data?) but "overlapping" Exceptions have to be dealt with.
> Alternatively it might be a good idea to log the Exceptions before throwing them, so that the stack trace isn't lost. This is probably easier than tracking in the finally block whether a previous Exception has been thrown, and what to do with it.
> If there's a workaround for this, that I might have missed, to get to the root of the Exception, I would also be interested in hearing, I'm currently looking at a situation where jdbc fails, and there being no indication of what's going on.
> I labelled this newbie-level, since the implementation is pretty trivial; but the decision of which way to pursue isn't as clear to me.



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