[ https://issues.apache.org/jira/browse/STORM-2028?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15423729#comment-15423729 ]
Salil Kanetkar edited comment on STORM-2028 at 8/17/16 1:33 AM: ---------------------------------------------------------------- Hi [~RPCMoritz], I am new to the open source community. I was looking for issues to contribute towards, and I think this issue would be a good starting point. I have started looking at the https://github.com/apache/storm/blob/master/external/storm-jdbc/src/main/java/org/apache/storm/jdbc/common/JdbcClient.java class. Any other part I should look into? was (Author: salilkanetkar): Hi [~RPCMoritz], I am new to the open source community. I was looking for issues to contribute, and I think this issue would be a good starting point. I have started looking at the https://github.com/apache/storm/blob/master/external/storm-jdbc/src/main/java/org/apache/storm/jdbc/common/JdbcClient.java class. Any other part I should look into? > 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 > Priority: Minor > Labels: newbie > > 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.3.4#6332)