[
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)
