Derby
  1. Derby
  2. DERBY-1439

Investigate removing the antiGC thread in embedded Derby

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 10.7.1.1
    • Component/s: Services
    • Labels:
      None

      Description

      The antiGC thread was originally created to avoid the DriverManager class being garbage collected when no refrences existed to it and it had loaded the embedded JDBC driver (and hence shutting down the engine). This was an issue with JDK 1.1. Since Derby does not support jdk1.1 and garbage collection of classes is clearly defined, it is possible the thread serves no useful purpose.

      1. d1439.diff
        6 kB
        Knut Anders Hatlen
      2. patch1.diff
        4 kB
        Knut Anders Hatlen

        Activity

        Hide
        Knut Anders Hatlen added a comment -

        [bulk update] Close all resolved issues that haven't been updated for more than one year.

        Show
        Knut Anders Hatlen added a comment - [bulk update] Close all resolved issues that haven't been updated for more than one year.
        Hide
        Knut Anders Hatlen added a comment -

        I've committed the patch (revision 1027552) so that we get more testing of it before 10.7. Hopefully, it doesn't cause any problems, but if it does, we can back it out from the 10.7 branch.

        Show
        Knut Anders Hatlen added a comment - I've committed the patch (revision 1027552) so that we get more testing of it before 10.7. Hopefully, it doesn't cause any problems, but if it does, we can back it out from the 10.7 branch.
        Hide
        Knut Anders Hatlen added a comment -

        Attaching a new patch that addresses the problem with the first patch. The patch makes the following changes:

        M java/engine/org/apache/derby/impl/services/monitor/BaseMonitor.java

        Remove the AntiGC class and the code that starts and stops the AntiGC thread.

        M java/engine/org/apache/derby/iapi/services/i18n/MessageService.java

        Make setFinder() void since its return value is no longer used.

        M java/engine/org/apache/derby/impl/services/monitor/FileMonitor.java

        Create a new daemon thread group if all the previously booted databases have been shut down and the old thread group have been destroyed.

        All the regression tests ran cleanly with the patch.

        Show
        Knut Anders Hatlen added a comment - Attaching a new patch that addresses the problem with the first patch. The patch makes the following changes: M java/engine/org/apache/derby/impl/services/monitor/BaseMonitor.java Remove the AntiGC class and the code that starts and stops the AntiGC thread. M java/engine/org/apache/derby/iapi/services/i18n/MessageService.java Make setFinder() void since its return value is no longer used. M java/engine/org/apache/derby/impl/services/monitor/FileMonitor.java Create a new daemon thread group if all the previously booted databases have been shut down and the old thread group have been destroyed. All the regression tests ran cleanly with the patch.
        Hide
        Knut Anders Hatlen added a comment -

        I tried the naive approach to removing AntiGC (see the attached patch1.diff), but that led to many IllegalThreadStateExceptions in suites.All. This can also be seen by shutting down the only booted database and rebooting it in the same JVM:

        ij> connect 'jdbc:derby:db1;create=true';
        ij> connect 'jdbc:derby:db1;shutdown=true';
        ERROR 08006: Database 'db1' shutdown.
        ij> connect 'jdbc:derby:db1';
        ERROR XJ040: Failed to start database 'db1' with class loader sun.misc.Launcher$AppClassLoader@fabe9, see the next exception for details.
        ERROR XJ001: Java exception: ': java.lang.IllegalThreadStateException'.

        The problem with removing AntiGC is that BaseMonitor has a daemon ThreadGroup in which all service threads are started. Since the thread group is a daemon group, it will be destroyed automatically when its thread count becomes zero. AntiGC would prevent the thread group from being destroyed as long as the driver was loaded, since it would stay alive until the driver was unloaded and keep the thread count greater than zero. When there is no AntiGC thread to keep up the thread count, it may go down to zero on database shutdown, as in the example above, even if the driver is still loaded. The next attempt to start a service thread will then fail, since one cannot add threads to a destroyed thread group.

        I suppose we could make the thread group a non-daemon group and destroy it manually when the driver is unloaded, but then we'd first have to wait for all service threads to complete, which may introduce possibilities for hangs on system shutdown (for example because of DERBY-594). Another option may be to detect that this has happened and create a new daemon group when needed.

        Show
        Knut Anders Hatlen added a comment - I tried the naive approach to removing AntiGC (see the attached patch1.diff), but that led to many IllegalThreadStateExceptions in suites.All. This can also be seen by shutting down the only booted database and rebooting it in the same JVM: ij> connect 'jdbc:derby:db1;create=true'; ij> connect 'jdbc:derby:db1;shutdown=true'; ERROR 08006: Database 'db1' shutdown. ij> connect 'jdbc:derby:db1'; ERROR XJ040: Failed to start database 'db1' with class loader sun.misc.Launcher$AppClassLoader@fabe9, see the next exception for details. ERROR XJ001: Java exception: ': java.lang.IllegalThreadStateException'. The problem with removing AntiGC is that BaseMonitor has a daemon ThreadGroup in which all service threads are started. Since the thread group is a daemon group, it will be destroyed automatically when its thread count becomes zero. AntiGC would prevent the thread group from being destroyed as long as the driver was loaded, since it would stay alive until the driver was unloaded and keep the thread count greater than zero. When there is no AntiGC thread to keep up the thread count, it may go down to zero on database shutdown, as in the example above, even if the driver is still loaded. The next attempt to start a service thread will then fail, since one cannot add threads to a destroyed thread group. I suppose we could make the thread group a non-daemon group and destroy it manually when the driver is unloaded, but then we'd first have to wait for all service threads to complete, which may introduce possibilities for hangs on system shutdown (for example because of DERBY-594 ). Another option may be to detect that this has happened and create a new daemon group when needed.

          People

          • Assignee:
            Knut Anders Hatlen
            Reporter:
            Daniel John Debrunner
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development