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

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

    Details

    • 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:

      Description

      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.

        Attachments

          Issue Links

            Activity

              People

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

                Dates

                • Created:
                  Updated:
                  Resolved:

                  Time Tracking

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