glassfish
  1. glassfish
  2. GLASSFISH-16349

[UB]Better document max-pool-size in the EJB setting

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 3.1
    • Fix Version/s: 3.1.1_dev
    • Component/s: docs
    • Labels:
      None

      Description

      In Application Development Guide-> Using Enterprise JavaBeans Technology-> Value Added Features-> Pooling and Caching, there is a note about steady-pool-size but not max-pool-size: "... parameter does not necessarily guarantee that no more than steady-pool-size instances exist at a given time. ...."

      It probably should say max-pool-size. Neither one is a bound value - they are rather the pool conditions (i.e. no more than max-pool-size instances can be in a pool at any given time, and when the pool is steady, it's size is determined by the steady-pool size variable).

      When document is updated, please send for review to Mahesh and me.

        Activity

        Hide
        Scott Fordin added a comment -

        The subsection in which the paragraph in question is located begins, "One of the most important parameters of GlassFish Server pooling is steady-pool-size. When steady-pool-size is set to greater than 0, the container not only pre-populates the bean pool with the specified number of beans, but also attempts to ensure that this number of beans is always available in the free pool. This ensures that there are enough beans in the ready to serve state to process user requests."

        The item to which you refer in this issue is the first sentence in the subsequent paragraph. The problem I'm having here is that most of this entire subsection talks about steady-pool-size. Are you saying it's sufficient to replace "steady-pool-size" with "max-pool-size" in just the one instance you cite? Or must the entire subsection be recast to focus on max-pool-size?

        Show
        Scott Fordin added a comment - The subsection in which the paragraph in question is located begins, "One of the most important parameters of GlassFish Server pooling is steady-pool-size. When steady-pool-size is set to greater than 0, the container not only pre-populates the bean pool with the specified number of beans, but also attempts to ensure that this number of beans is always available in the free pool. This ensures that there are enough beans in the ready to serve state to process user requests." The item to which you refer in this issue is the first sentence in the subsequent paragraph. The problem I'm having here is that most of this entire subsection talks about steady-pool-size. Are you saying it's sufficient to replace "steady-pool-size" with "max-pool-size" in just the one instance you cite? Or must the entire subsection be recast to focus on max-pool-size?
        Hide
        marina vatkina added a comment -

        May be we should mention both in the 2nd par?

        Show
        marina vatkina added a comment - May be we should mention both in the 2nd par?
        Hide
        Scott Fordin added a comment -

        After following up with Marina, we reworked the subsection to read as follows:

        ---------------------------------- Snip ----------------------------------
        One of the most important parameters for GlassFish Server pooling is steady-pool-size. When steady-pool-size is set to a value greater than 0, the container not only pre-populates the bean pool with the specified number of beans, but also attempts to ensure that this number of beans is always available in the free pool. This ensures that there are enough beans in the ready-to-serve state to process user requests.

        Note that the steady-pool-size and max-pool-size parameters only govern the number of instances that are pooled over a long period of time. They do not necessarily guarantee that the number of instances that may exist in the JVM at a given time will not exceed the value specified by max-pool-size. For example, suppose an idle stateless session container has a fully-populated pool with a steady-pool-size of 10. If 20 concurrent requests arrive for the EJB component, the container creates 10 additional instances to satisfy the burst of requests. The advantage of this is that it prevents the container from blocking any of the incoming requests. However, if the activity dies down to 10 or fewer concurrent requests, the additional 10 instances are discarded.

        Another parameter, pool-idle-timeout-in-seconds, allows the administrator to specify the amount of time a bean instance can be idle in the pool. When pool-idle-timeout-in-seconds is set to greater than 0, the container removes or destroys any bean instance that is idle for this specified duration.
        ---------------------------------- Snip ----------------------------------

        Show
        Scott Fordin added a comment - After following up with Marina, we reworked the subsection to read as follows: ---------------------------------- Snip ---------------------------------- One of the most important parameters for GlassFish Server pooling is steady-pool-size. When steady-pool-size is set to a value greater than 0, the container not only pre-populates the bean pool with the specified number of beans, but also attempts to ensure that this number of beans is always available in the free pool. This ensures that there are enough beans in the ready-to-serve state to process user requests. Note that the steady-pool-size and max-pool-size parameters only govern the number of instances that are pooled over a long period of time. They do not necessarily guarantee that the number of instances that may exist in the JVM at a given time will not exceed the value specified by max-pool-size. For example, suppose an idle stateless session container has a fully-populated pool with a steady-pool-size of 10. If 20 concurrent requests arrive for the EJB component, the container creates 10 additional instances to satisfy the burst of requests. The advantage of this is that it prevents the container from blocking any of the incoming requests. However, if the activity dies down to 10 or fewer concurrent requests, the additional 10 instances are discarded. Another parameter, pool-idle-timeout-in-seconds, allows the administrator to specify the amount of time a bean instance can be idle in the pool. When pool-idle-timeout-in-seconds is set to greater than 0, the container removes or destroys any bean instance that is idle for this specified duration. ---------------------------------- Snip ----------------------------------
        Hide
        scatari added a comment -

        Updating the fix in version to correct build #.

        Show
        scatari added a comment - Updating the fix in version to correct build #.

          People

          • Assignee:
            Scott Fordin
            Reporter:
            marina vatkina
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: