OpenJPA
  1. OpenJPA
  2. OPENJPA-1713

OutOfMemory caused by EntityManagerImpl.push/popFetchPlan processing

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.1.0, 1.2.2, 2.0.0
    • Fix Version/s: 2.0.1, 2.1.0
    • Component/s: kernel
    • Labels:
      None

      Description

      There is a leak in memory in the EntityManagerImpl push/popFetchPlan processing where fetch plan associated with the current fetch configuration is add to the _plans IdentityHashMap but never remove from it.

      private Map<FetchConfiguration,FetchPlan> _plans = new IdentityHashMap<FetchConfiguration,FetchPlan>(1);

      public FetchPlan getFetchPlan() {
      assertNotCloseInvoked();
      _broker.lock();
      try {
      FetchConfiguration fc = _broker.getFetchConfiguration();
      FetchPlan fp = _plans.get(fc);
      if (fp == null)

      { fp = _emf.toFetchPlan(_broker, fc); _plans.put(fc, fp); <<< added to _plans }

      return fp;
      } finally

      { _broker.unlock(); }
      }

      public FetchPlan pushFetchPlan() {
      assertNotCloseInvoked();
      _broker.lock();
      try { _broker.pushFetchConfiguration(); return getFetchPlan(); } finally { _broker.unlock(); }

      }

      public void popFetchPlan() {
      assertNotCloseInvoked();
      _broker.lock();
      try

      { _broker.popFetchConfiguration(); <<< but never remove when the fetch plan is popped. }

      finally

      { _broker.unlock(); }

      }

      The only time _plans is cleaned up are during clear() or closed().

        Activity

        Hide
        Michael Dick added a comment -

        Targeting for 2.0.1.

        Show
        Michael Dick added a comment - Targeting for 2.0.1.
        Hide
        Donald Woods added a comment -

        Is this ready to mark as resolved for 2.0.1 and trunk? No activity since July 7th.....

        Show
        Donald Woods added a comment - Is this ready to mark as resolved for 2.0.1 and trunk? No activity since July 7th.....

          People

          • Assignee:
            Albert Lee
            Reporter:
            Albert Lee
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development