Uploaded image for project: 'MariaDB Connector/J'
  1. MariaDB Connector/J
  2. CONJ-1

Timeout exceptions when using Apache DBCP properties

Details

    • Bug
    • Status: Closed (View Workflow)
    • Major
    • Resolution: Fixed
    • None
    • None
    • None
    • None

    Description

      When using validation-query and validation-query-timeout for them ("SELECT 1" and a timeout of 3), timeout exceptions occur in all queries. If the validation-query-timeout parameter (and only that one) is removed, everything works as expected.

      These are Apache DBCP properties.

      Attachments

        Activity

          Reaching out to user that experienced this to get more information.

          ratzpo Rasmus Johansson (Inactive) added a comment - Reaching out to user that experienced this to get more information.

          I tried a lot of things (without DBCP, since I do not have any knowlegde about it), and could not see any difference in how setQueryTimeout/getQuerytimeout behave between ConnectorJ and MariaDB JDBC.

          I guess we need a runnable self-contained repro, be it DBCP or anything else.

          wlad Vladislav Vaintroub added a comment - I tried a lot of things (without DBCP, since I do not have any knowlegde about it), and could not see any difference in how setQueryTimeout/getQuerytimeout behave between ConnectorJ and MariaDB JDBC. I guess we need a runnable self-contained repro, be it DBCP or anything else.

          I think I fixed it now. I did not try DBCP, but playing around with timeouts revealed JVM bug in socket timeouts that were used for query timeout. So this got reimplemented again with java.util.Timer.

          wlad Vladislav Vaintroub added a comment - I think I fixed it now. I did not try DBCP, but playing around with timeouts revealed JVM bug in socket timeouts that were used for query timeout. So this got reimplemented again with java.util.Timer.

          This fix solved the timeout exceptions, however it creates a resource leak as the Timer is not being cancelled and nulled. See attached patch

          george George El Boustani added a comment - This fix solved the timeout exceptions, however it creates a resource leak as the Timer is not being cancelled and nulled. See attached patch

          Patch:

          === modified file 'src/main/java/org/mariadb/jdbc/MySQLStatement.java'
          --- src/main/java/org/mariadb/jdbc/MySQLStatement.java	2012-12-25 15:38:29 +0000
          +++ src/main/java/org/mariadb/jdbc/MySQLStatement.java	2013-01-04 01:26:09 +0000
          @@ -373,6 +373,9 @@
                           }
                       }
                   }
          +
          +        cancelTimer();
          +
                   isClosed = true;
               }
           
          @@ -498,6 +501,8 @@
               public void cancel() throws SQLException {
                   try {
                       protocol.cancelCurrentQuery();
          +
          +            cancelTimer();
                   } catch (QueryException e) {
                       SQLExceptionMapper.throwException(e, connection, this);
           
          @@ -1182,4 +1187,11 @@
           		// TODO Auto-generated method stub
           		return false;
           	}
          +
          +    private void cancelTimer() {
          +        if (timer != null) {
          +            timer.cancel();
          +            timer = null;
          +        }
          +    }
           }

          george George El Boustani added a comment - Patch: === modified file 'src/main/java/org/mariadb/jdbc/MySQLStatement.java' --- src/main/java/org/mariadb/jdbc/MySQLStatement.java 2012-12-25 15:38:29 +0000 +++ src/main/java/org/mariadb/jdbc/MySQLStatement.java 2013-01-04 01:26:09 +0000 @@ -373,6 +373,9 @@ } } } + + cancelTimer(); + isClosed = true; } @@ -498,6 +501,8 @@ public void cancel() throws SQLException { try { protocol.cancelCurrentQuery(); + + cancelTimer(); } catch (QueryException e) { SQLExceptionMapper.throwException(e, connection, this); @@ -1182,4 +1187,11 @@ // TODO Auto-generated method stub return false; } + + private void cancelTimer() { + if (timer != null) { + timer.cancel(); + timer = null; + } + } }

          Before the patch over 3000 threads were running, and after it was down to 80

          george George El Boustani added a comment - Before the patch over 3000 threads were running, and after it was down to 80

          thanks. Would it be possible for you to paste a test case for "3000 threads are running"?

          wlad Vladislav Vaintroub added a comment - thanks. Would it be possible for you to paste a test case for "3000 threads are running"?

          After reading docs for java.util.Timer - yes, you're right that there are excessive threads when using multiple timers. So ,the way to fix is it, is to use single (per-JVM) timer with multiple timerTasks , which I done in this patch :
          http://bazaar.launchpad.net/~maria-captains/mariadb-java-client/trunk/revision/376

          wlad Vladislav Vaintroub added a comment - After reading docs for java.util.Timer - yes, you're right that there are excessive threads when using multiple timers. So ,the way to fix is it, is to use single (per-JVM) timer with multiple timerTasks , which I done in this patch : http://bazaar.launchpad.net/~maria-captains/mariadb-java-client/trunk/revision/376

          People

            wlad Vladislav Vaintroub
            ratzpo Rasmus Johansson (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved:

              Git Integration

                Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.