[jira] [Comment Edited] (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:comment-tabpanel&focusedCommentId=15426427#comment-15426427 ] Rick Moritz edited comment on STORM-2028 at 8/18/16 1:20 PM: - >From my analysis, this issue is restricted to that class, so I think you >should be able to solve it within that scope. was (Author: rpcmoritz): >From my analysis, this is issue is restricted to that class, so I think you >should be able to solve it within that scope. > 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)
[jira] [Comment Edited] (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: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)
