glassfish
  1. glassfish
  2. GLASSFISH-11170

ejb bean pool steady & max size being ignored

    Details

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

      Operating System: All
      Platform: All

    • Issuezilla Id:
      11,170
    • Status Whiteboard:
      Hide

      v3_exclude

      Show
      v3_exclude

      Description

      The ejb-container is resizing its stateless session bean pool even if the pool
      max and steady sizes are set to the same value. My max-pool-size is 60 and
      steady-pool-size is 60, but the #of beans in the pool regularly slips to
      anything between 57-62. With low loads on SPECjEnterprise2010, 2% of time is
      spent in resizing this pool.

        Activity

        Hide
        Dies Koper added a comment -

        In GFv2.1 we noticed a similar issue: with concurrent access from a Java EE
        client to a SLSB the number of instances in the pool. Marina asked me to put our
        findings here as it might help with the investigation of this issue.

        We had the following pool settings:
        cluster.ejb-container.steady-pool-size = 20
        cluster.ejb-container.pool-resize-quantity = 10
        cluster.ejb-container.max-pool-size = 21
        cluster.ejb-container.pool-idle-timeout-in-seconds = 1

        In the monitor GUI the values for current and maximum number of instances in the
        pool would go as high as 30.

        In GFv2.1 we found the following in NonBlockingPool.java.
        Code that adds instances:

        • doResize()
          1. enters synchronized block
          2. calculates number of instances in pool, etc.
          3. leaves synchronized block
          4. creates instances as required and adds them to the list

        Code that processes instances after they're used:

        • returnObject()
          1. enters synchronized block
          2. if the size of the list is less than pool max, instances are added. If
          more, those instances are destroyed.
          3. leaves synchronized block

        So if doResize() is called concurrently, the calculation in step 2. is affected
        by step 4. in the other thread.

        Show
        Dies Koper added a comment - In GFv2.1 we noticed a similar issue: with concurrent access from a Java EE client to a SLSB the number of instances in the pool. Marina asked me to put our findings here as it might help with the investigation of this issue. We had the following pool settings: cluster.ejb-container.steady-pool-size = 20 cluster.ejb-container.pool-resize-quantity = 10 cluster.ejb-container.max-pool-size = 21 cluster.ejb-container.pool-idle-timeout-in-seconds = 1 In the monitor GUI the values for current and maximum number of instances in the pool would go as high as 30. In GFv2.1 we found the following in NonBlockingPool.java. Code that adds instances: doResize() 1. enters synchronized block 2. calculates number of instances in pool, etc. 3. leaves synchronized block 4. creates instances as required and adds them to the list Code that processes instances after they're used: returnObject() 1. enters synchronized block 2. if the size of the list is less than pool max, instances are added. If more, those instances are destroyed. 3. leaves synchronized block So if doResize() is called concurrently, the calculation in step 2. is affected by step 4. in the other thread.
        Hide
        Dies Koper added a comment -

        Created an attachment (id=4002)
        patch based on GFv2.1 source, might be portable to GFv3.x?

        Show
        Dies Koper added a comment - Created an attachment (id=4002) patch based on GFv2.1 source, might be portable to GFv3.x?
        Hide
        Mahesh Kannan added a comment -

        Taking ownership

        Show
        Mahesh Kannan added a comment - Taking ownership
        Hide
        Mahesh Kannan added a comment -

        This is not a show stopper for v3

        Show
        Mahesh Kannan added a comment - This is not a show stopper for v3
        Hide
        kumara added a comment -

        Setting target release for unresolved issues submitted on v3 release to the next release. Not changing
        issues submitted on v2.x release because they might not apply to v3.next release.

        Show
        kumara added a comment - Setting target release for unresolved issues submitted on v3 release to the next release. Not changing issues submitted on v2.x release because they might not apply to v3.next release.
        Hide
        Dies Koper added a comment -

        The offending code hasn't been changed in V3/V3.1.
        May I commit the patch to GFv3.1?

        Show
        Dies Koper added a comment - The offending code hasn't been changed in V3/V3.1. May I commit the patch to GFv3.1?
        Hide
        Mahesh Kannan added a comment -

        Yes

        Show
        Mahesh Kannan added a comment - Yes
        Hide
        Mahesh Kannan added a comment -

        Yes, Please commit the patch

        Show
        Mahesh Kannan added a comment - Yes, Please commit the patch
        Hide
        Dies Koper added a comment -

        Fixed:

        Sending
        ejb\ejb-container\src\main\java\com\sun\ejb\containers\util\pool\NonBlockingPool.java
        Transmitting file data .
        Committed revision 41534.

        Show
        Dies Koper added a comment - Fixed: Sending ejb\ejb-container\src\main\java\com\sun\ejb\containers\util\pool\NonBlockingPool.java Transmitting file data . Committed revision 41534.

          People

          • Assignee:
            Dies Koper
            Reporter:
            rahulbiswas
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: