Derby
  1. Derby
  2. DERBY-4432

Memory leak when attempting to boot non-existing database with the in-memory back end

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 10.5.3.0, 10.6.1.0
    • Fix Version/s: 10.5.3.1, 10.6.1.0
    • Component/s: Store
    • Labels:
      None
    • Environment:
      In-memory back end and large amount of boot attempts of non-existing databases.
    • Issue & fix info:
      Release Note Needed

      Description

      When attempting to boot a non-existing database with the in-memory back end, a DataStore is created and referenced by a map. Since the database doesn't exist, Derby won't use the DataStore again and it will hang around indefinitely in VFMemoryStorageFactory (or until the same database is actually created, in which case the data store will be used).

      FYI, storage factory instances are instantiated liberally, including for the same service (i.e. six instances of VFMemoryStorageFactory may be created to boot "jdbc:derby:memory:myDB").

      1. releaseNote.html
        4 kB
        Kristian Waagan
      2. derby-4432-1a-mem_leak_fix.stat
        0.2 kB
        Kristian Waagan
      3. derby-4432-1a-mem_leak_fix.diff
        7 kB
        Kristian Waagan

        Issue Links

          Activity

          Hide
          Kristian Waagan added a comment -

          Patch 1a fixes the memory leak and adds a test for it.

          A "dummy" data store has been added. It will be used until Derby actually requests a database to be created (when a unique name is provided).
          Directories for created databases will be created in the dummy data store, which means it will grow with the number of databases created. I don't think this will be a problem, because the space occupied by the databases themselves will be much larger than the bytes required to store a directory structure. Further, I intended to delete the directory structure in the dummy store for a database when the database itself is deleted (this patch will probably appear under DERBY-4428).

          An alternative to the current patch is to use a bounded map where the oldest entry is deleted when the bound has been exceeded. I discarded this approach because the code got slightly more complex.

          Patch ready for review.

          Show
          Kristian Waagan added a comment - Patch 1a fixes the memory leak and adds a test for it. A "dummy" data store has been added. It will be used until Derby actually requests a database to be created (when a unique name is provided). Directories for created databases will be created in the dummy data store, which means it will grow with the number of databases created. I don't think this will be a problem, because the space occupied by the databases themselves will be much larger than the bytes required to store a directory structure. Further, I intended to delete the directory structure in the dummy store for a database when the database itself is deleted (this patch will probably appear under DERBY-4428 ). An alternative to the current patch is to use a bounded map where the oldest entry is deleted when the bound has been exceeded. I discarded this approach because the code got slightly more complex. Patch ready for review.
          Hide
          Kristian Waagan added a comment -

          Forgot to mention that patch 1a changes the behavior slightly. The in-memory back end will now behave more like the on-disk back end in that you won't be able to create database "/tmp/a" if you have already created database "/tmp/a/b" (there may be some exceptions for both back ends when Derby is instructed to delete the existing service root). The reason is the check for whether the service root already exists or not.

          Show
          Kristian Waagan added a comment - Forgot to mention that patch 1a changes the behavior slightly. The in-memory back end will now behave more like the on-disk back end in that you won't be able to create database "/tmp/a" if you have already created database "/tmp/a/b" (there may be some exceptions for both back ends when Derby is instructed to delete the existing service root). The reason is the check for whether the service root already exists or not.
          Hide
          Kristian Waagan added a comment -

          Regression tests ran cleanly on trunk with patch 1a.
          Committed patch 1a to trunk with revision 834418.

          Will check if it is suited for back-port and rerun tests on the 10.5 branch if that is the case.

          Show
          Kristian Waagan added a comment - Regression tests ran cleanly on trunk with patch 1a. Committed patch 1a to trunk with revision 834418. Will check if it is suited for back-port and rerun tests on the 10.5 branch if that is the case.
          Hide
          Kristian Waagan added a comment -

          Back-ported patch 1a to the 10.5 branch with revision 835290.
          Attached first revision of a release note, as the change may break existing applications using the in-memory back end. The incompatibility will normally not be triggered, which is why I chose to back-port the fix.

          Show
          Kristian Waagan added a comment - Back-ported patch 1a to the 10.5 branch with revision 835290. Attached first revision of a release note, as the change may break existing applications using the in-memory back end. The incompatibility will normally not be triggered, which is why I chose to back-port the fix.

            People

            • Assignee:
              Kristian Waagan
              Reporter:
              Kristian Waagan
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development