Rick Moritz created STORM-2028:
----------------------------------
Summary: 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
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)
