Uploaded image for project: 'Apache Storm'
  1. Apache Storm
  2. STORM-2028

Exceptions in JDBCClient are hidden by subsequent SQL-Exception in close()



    • Type: Bug
    • Status: Resolved
    • Priority: Minor
    • Resolution: Fixed
    • Affects Version/s: 2.0.0
    • Fix Version/s: 2.0.0
    • Component/s: storm-jdbc
    • Labels:


      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.


          Issue Links



              • Assignee:
                CobraCrowe Rahul Jain
                RPCMoritz Rick Moritz
              • Votes:
                0 Vote for this issue
                4 Start watching this issue


                • Created:

                  Time Tracking

                  Original Estimate - Not Specified
                  Not Specified
                  Remaining Estimate - 0h
                  Time Spent - 2h 40m
                  2h 40m