Derby
  1. Derby
  2. DERBY-594

Some rawStoreDaemon threads are not stopped

    Details

    • Type: Bug Bug
    • Status: Open
    • Priority: Minor Minor
    • Resolution: Unresolved
    • Affects Version/s: 10.1.2.1, 10.2.1.6
    • Fix Version/s: None
    • Component/s: Services
    • Environment:
      Solaris 10 x86, NetBSD 2.1 (x86), Sun JDK 1.4.2/1.5.0
    • Urgency:
      Normal

      Description

      In some cases, loading a database will create a rawStoreDaemon thread
      which will run forever, even after Derby is shut down with
      DriverManager.getConnection("jdbc:derby:;shutdown=true").

      I have found two tests in derbyall (there are probably more) where
      threads are left running:

      • in store/rollForwardBackup.sql two threads are never terminated
      • in store/encryptDatabase.sql five threads are never terminated

      All the threads are named "derby.rawStoreDaemon" and created in
      org.apache.derby.impl.store.raw.RawStore.boot().

      It seems like this happens in some (but not all) cases where the
      loading of a database fails, but I am not able to say exactly what
      triggers this bug yet.

        Activity

        Knut Anders Hatlen created issue -
        Knut Anders Hatlen made changes -
        Field Original Value New Value
        Status Open [ 1 ] In Progress [ 3 ]
        Hide
        Knut Anders Hatlen added a comment -

        I haven't had time to work on this issue for a long time. Just thought
        I'd summarize what I have found out till now in case someone is
        interested.

        TopService.bootModule() has a try/catch like this:

        try

        { BaseMonitor.boot(instance, create, properties); }

        catch (StandardException se)

        { moduleInstances.removeElement(module); throw se; }

        If an exception is thrown in BaseMonitor.boot(), daemon threads might
        have been started, but they are not shut down. This can be solved by
        putting

        TopService.stop(instance);

        in the catch block.

        However, this leads to two problems:

        1) LogToFile.stop() gets a NullPointerException in
        deleteObsoleteLogfiles() because currentCheckpoint is null. This
        is easily solved by adding a test for currentCheckpoint == null
        and not calling deleteObsoleteLogfiles() if that's the case.

        2) If one tries to boot a database that is already booted in another
        JVM, BaseMonitor.boot() will fail. However, the call to
        TopService.stop() will delete the boot lock, even though it
        belongs to another process. Therefore, trying once more to boot
        the database will succeed. The solution to this problem is
        probably to set a flag (e.g., ownerOfBootLock) when creating the
        boot lock file, and to check the value of the flag before
        deleting the file.

        Show
        Knut Anders Hatlen added a comment - I haven't had time to work on this issue for a long time. Just thought I'd summarize what I have found out till now in case someone is interested. TopService.bootModule() has a try/catch like this: try { BaseMonitor.boot(instance, create, properties); } catch (StandardException se) { moduleInstances.removeElement(module); throw se; } If an exception is thrown in BaseMonitor.boot(), daemon threads might have been started, but they are not shut down. This can be solved by putting TopService.stop(instance); in the catch block. However, this leads to two problems: 1) LogToFile.stop() gets a NullPointerException in deleteObsoleteLogfiles() because currentCheckpoint is null. This is easily solved by adding a test for currentCheckpoint == null and not calling deleteObsoleteLogfiles() if that's the case. 2) If one tries to boot a database that is already booted in another JVM, BaseMonitor.boot() will fail. However, the call to TopService.stop() will delete the boot lock, even though it belongs to another process. Therefore, trying once more to boot the database will succeed. The solution to this problem is probably to set a flag (e.g., ownerOfBootLock) when creating the boot lock file, and to check the value of the flag before deleting the file.
        Hide
        Daniel John Debrunner added a comment -

        Possible blocks DERBY-538, during some tests with my changes for 538 backups are failing due to the JarClassLoader keeping the jar file open of the shutdown database. So something is keeping a reference to database objects, haven't investigated it yet.

        Show
        Daniel John Debrunner added a comment - Possible blocks DERBY-538 , during some tests with my changes for 538 backups are failing due to the JarClassLoader keeping the jar file open of the shutdown database. So something is keeping a reference to database objects, haven't investigated it yet.
        Daniel John Debrunner made changes -
        Link This issue blocks DERBY-538 [ DERBY-538 ]
        Hide
        Daniel John Debrunner added a comment -

        Confirmed that this is not an issue for DERBY-538, the raw store daemon thread stops correctly in the situation I'm seeing.

        Show
        Daniel John Debrunner added a comment - Confirmed that this is not an issue for DERBY-538 , the raw store daemon thread stops correctly in the situation I'm seeing.
        Knut Anders Hatlen made changes -
        Status In Progress [ 3 ] Open [ 1 ]
        Hide
        Knut Anders Hatlen added a comment -

        Unassigning the issue since I am not working on it.

        Show
        Knut Anders Hatlen added a comment - Unassigning the issue since I am not working on it.
        Knut Anders Hatlen made changes -
        Assignee Knut Anders Hatlen [ knutanders ]
        Daniel John Debrunner made changes -
        Link This issue blocks DERBY-538 [ DERBY-538 ]
        Hide
        Mike Matrigali added a comment -

        Triaged July 2, 2009: assigned normal urgency.

        Show
        Mike Matrigali added a comment - Triaged July 2, 2009: assigned normal urgency.
        Mike Matrigali made changes -
        Urgency Normal
        Kathey Marsden made changes -
        Labels derby_triage10_5_2
        Gavin made changes -
        Workflow jira [ 12330666 ] Default workflow, editable Closed status [ 12799484 ]

          People

          • Assignee:
            Unassigned
            Reporter:
            Knut Anders Hatlen
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:

              Development