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

Connection cannot be closed without closing a resultset if fetching is not done, close() hangs

    XMLWordPrintable

Details

    • Bug
    • Status: Closed (View Workflow)
    • Minor
    • Resolution: Fixed
    • 1.1.0
    • 1.1.1
    • None
    • None

    Description

      I think it's a minor issue because JDBC does not explicitly state that Connection.close() must close a statement and result sets; but in the current state it's particularly error-prone, and hanging isn't good, so if it's possible, it would be good to fix. MySQL Connector/J doesn't show this problem.

      The following test case sets a non-zero fetch size for a statement and then executes a query with a sizable enough result set. Before all values are fetched, the connection gets closed, but the operation never ends.

      Test case:

      import java.sql.DriverManager;
      import java.sql.Connection;
      import java.sql.Statement;
      import java.sql.ResultSet;
       
       
      public class NonFinishedFetch
      {
       
        public static void main (String argv[]) throws Exception
        {
          try {
            String dsn = "jdbc:mysql://localhost:3306/test?user=root";
            Statement stmt = null;
            ResultSet rs = null;
            Connection conn = DriverManager.getConnection(dsn);
            stmt = conn.createStatement();
            stmt.execute("DROP TABLE IF EXISTS t1");
            stmt.execute("CREATE TABLE t1 (a VARCHAR(1024))");
            String st = "INSERT INTO t1 VALUES (REPEAT('a',1024))";
            for ( int i=1; i<=100; i++) {
              st = st + ",(REPEAT('a',1024))";
            }
            stmt.setFetchSize(Integer.MIN_VALUE);
            stmt.execute(st);
            rs = stmt.executeQuery("SELECT * FROM t1 a, t1 b");
            conn.close();  
          } catch (Exception e) {
            e.printStackTrace();
          }
        } 
      }

      Stack trace:

      Full thread dump OpenJDK 64-Bit Server VM (20.0-b12 mixed mode):
       
      "Attach Listener" daemon prio=10 tid=0x0000000001afe000 nid=0x2089 runnable [0x0000000000000000]
         java.lang.Thread.State: RUNNABLE
       
         Locked ownable synchronizers:
      	- None
       
      "Low Memory Detector" daemon prio=10 tid=0x0000000001a0b800 nid=0x2079 runnable [0x0000000000000000]
         java.lang.Thread.State: RUNNABLE
       
         Locked ownable synchronizers:
      	- None
       
      "C2 CompilerThread1" daemon prio=10 tid=0x0000000001a06800 nid=0x2078 waiting on condition [0x0000000000000000]
         java.lang.Thread.State: RUNNABLE
       
         Locked ownable synchronizers:
      	- None
       
      "C2 CompilerThread0" daemon prio=10 tid=0x0000000001a03800 nid=0x2077 waiting on condition [0x0000000000000000]
         java.lang.Thread.State: RUNNABLE
       
         Locked ownable synchronizers:
      	- None
       
      "Signal Dispatcher" daemon prio=10 tid=0x0000000001a02800 nid=0x2076 runnable [0x0000000000000000]
         java.lang.Thread.State: RUNNABLE
       
         Locked ownable synchronizers:
      	- None
       
      "Finalizer" daemon prio=10 tid=0x00000000019e3800 nid=0x2075 in Object.wait() [0x00007f8985d2f000]
         java.lang.Thread.State: WAITING (on object monitor)
      	at java.lang.Object.wait(Native Method)
      	- waiting on <0x00000000ec7782c0> (a java.lang.ref.ReferenceQueue$Lock)
      	at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:133)
      	- locked <0x00000000ec7782c0> (a java.lang.ref.ReferenceQueue$Lock)
      	at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:149)
      	at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:177)
       
         Locked ownable synchronizers:
      	- None
       
      "Reference Handler" daemon prio=10 tid=0x00000000019dc000 nid=0x2074 in Object.wait() [0x00007f8985e30000]
         java.lang.Thread.State: WAITING (on object monitor)
      	at java.lang.Object.wait(Native Method)
      	- waiting on <0x00000000ec778360> (a java.lang.ref.Reference$Lock)
      	at java.lang.Object.wait(Object.java:502)
      	at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:133)
      	- locked <0x00000000ec778360> (a java.lang.ref.Reference$Lock)
       
         Locked ownable synchronizers:
      	- None
       
      "main" prio=10 tid=0x0000000001971800 nid=0x2070 runnable [0x00007f898cbd8000]
         java.lang.Thread.State: RUNNABLE
      	at java.net.SocketInputStream.socketRead0(Native Method)
      	at java.net.SocketInputStream.read(SocketInputStream.java:146)
      	at java.net.SocketInputStream.read(SocketInputStream.java:199)
      	at org.mariadb.jdbc.internal.mysql.MySQLProtocol.close(MySQLProtocol.java:563)
      	at org.mariadb.jdbc.internal.mysql.MySQLProtocol.close(MySQLProtocol.java:589)
      	at org.mariadb.jdbc.MySQLConnection.close(MySQLConnection.java:257)
      	at NonFinishedFetch.main(NonFinishedFetch.java:27)
       
         Locked ownable synchronizers:
      	- None
       
      "VM Thread" prio=10 tid=0x00000000019d5000 nid=0x2073 runnable 
       
      "GC task thread#0 (ParallelGC)" prio=10 tid=0x000000000197c800 nid=0x2071 runnable 
       
      "GC task thread#1 (ParallelGC)" prio=10 tid=0x000000000197e000 nid=0x2072 runnable 
       
      "VM Periodic Task Thread" prio=10 tid=0x0000000001a0e000 nid=0x207a waiting on condition 
       
      JNI global references: 885

      revision-id: wlad@montyprogram.com-20130213220529-3nt9agupszq2cufk
      revno: 409
      branch-nick: mariadb-java-client

      Attachments

        Activity

          People

            wlad Vladislav Vaintroub
            elenst Elena Stepanova
            Votes:
            0 Vote for this issue
            Watchers:
            1 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.