glassfish
  1. glassfish
  2. GLASSFISH-13539

OOM when deploying EJB app with big max cache size setting

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 3.1
    • Fix Version/s: 3.1_b32
    • Component/s: ejb_container
    • Labels:
      None
    • Environment:

      Operating System: Windows XP
      Platform: All

    • Issuezilla Id:
      13,539

      Description

      I set max-cache-size in sun-ejb-jar.xml to a big value (2147483646) so I can
      monitor the caching and tune accordingly.
      However, at deploy time I get an out of memory error on
      glassfish-3.1-b21-09_17_2010. It worked fine on GFv2.1.

      The server log has:

      Caused by: java.lang.OutOfMemoryError: Java heap space
      at com.sun.ejb.containers.util.cache.BaseCache.init(BaseCache.java:205)
      at com.sun.ejb.containers.util.cache.NRUSessionCache.init(NRUSessionCache.java:61)
      at
      com.sun.ejb.containers.builder.StatefulContainerBuilder.buildCache(StatefulContainerBuilder.java:327)

      I've reported a similar issue in the past for jdbc (issue 8425).
      Maybe you can fix this one in a similar way?

        Activity

        Hide
        Dies Koper added a comment -

        Created an attachment (id=4919)
        test app (may need to create 'jdbc/JPA' resource before deployment)

        Show
        Dies Koper added a comment - Created an attachment (id=4919) test app (may need to create 'jdbc/JPA' resource before deployment)
        Hide
        Mahesh Kannan added a comment -

        2147483646 (2Gb?) is really large. BTW, what was the max heap size of your VM?

        Show
        Mahesh Kannan added a comment - 2147483646 (2Gb?) is really large. BTW, what was the max heap size of your VM?
        Hide
        Dies Koper added a comment -

        I used default settings.

        But that is not the point.
        Please also refer to the issue I referred to.

        The current code is flawed as it blindly tries to reserve memory to hold all
        objects it may at one point need to hold.
        One would expect a cache only to use a lot of memory when it has been used for a
        while and the cache fills up. As you monitor its size, you tune its maximum
        (after all, you can't easily calculate in advance how many objects will take up
        how much memory space, which is the actual constrained resource).

        As it worked fine in GFv2, this can also be seen as a regression/migration issue.

        Hope that helps.

        Show
        Dies Koper added a comment - I used default settings. But that is not the point. Please also refer to the issue I referred to. The current code is flawed as it blindly tries to reserve memory to hold all objects it may at one point need to hold. One would expect a cache only to use a lot of memory when it has been used for a while and the cache fills up. As you monitor its size, you tune its maximum (after all, you can't easily calculate in advance how many objects will take up how much memory space, which is the actual constrained resource). As it worked fine in GFv2, this can also be seen as a regression/migration issue. Hope that helps.
        Hide
        Mahesh Kannan added a comment -

        Will look into this.

        Show
        Mahesh Kannan added a comment - Will look into this.
        Hide
        Mahesh Kannan added a comment -

        I have a fix for this. The OOM occurs because the caches attempt to allocate max-cache-size number of buckets upfront. The fix is to allocate a maximum of MAX_BUCKETS number of buckets. This way we can leave max-cache-size to controll the maximum number of entries that can stay in the cache whereas MAX_BUCKETS Will controll the concurrency.

        The default value for MAX_BUCKETS is 32768 but it can be set to any arbitrary value by using "com.sun.ejb.containers.MAX_BUCKETS" system property to a non zero, positive number.

        Show
        Mahesh Kannan added a comment - I have a fix for this. The OOM occurs because the caches attempt to allocate max-cache-size number of buckets upfront. The fix is to allocate a maximum of MAX_BUCKETS number of buckets. This way we can leave max-cache-size to controll the maximum number of entries that can stay in the cache whereas MAX_BUCKETS Will controll the concurrency. The default value for MAX_BUCKETS is 32768 but it can be set to any arbitrary value by using "com.sun.ejb.containers.MAX_BUCKETS" system property to a non zero, positive number.
        Hide
        Mahesh Kannan added a comment -

        Resolved

        Sending ejb-container/src/main/java/com/sun/ejb/containers/util/cache/BaseCache.java
        Transmitting file data .
        Committed revision 43522.

        Show
        Mahesh Kannan added a comment - Resolved Sending ejb-container/src/main/java/com/sun/ejb/containers/util/cache/BaseCache.java Transmitting file data . Committed revision 43522.

          People

          • Assignee:
            Mahesh Kannan
            Reporter:
            Dies Koper
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: