[jira] Assigned: (OPENEJB-1235) New Stateless pool options: PoolMin, IdleTimeout, MaxAge, Flush and more

["David Blevins (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/OPENEJB-1235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Blevins reassigned OPENEJB-1235:
--------------------------------------

    Assignee: David Blevins

> New Stateless pool options: PoolMin, IdleTimeout, MaxAge, Flush and more
> ------------------------------------------------------------------------
>
>                 Key: OPENEJB-1235
>                 URL: https://issues.apache.org/jira/browse/OPENEJB-1235
>             Project: OpenEJB
>          Issue Type: Improvement
>            Reporter: David Blevins
>            Assignee: David Blevins
>             Fix For: 3.1.3
>
>         Attachments: OPENEJB-1235.txt
>
>
>     # Specifies the minimum number of bean instances that should be
>     # in the pool for each bean.  Pools are prefilled to the minimum
>     # on startup.  Pool "shrinking" is achived through WeakReferences
>     # and natural vm garbage collection. All but the minimum are allowed
>     # to be garbage collected by the VM when memory is needed.
>     PoolMin 0
>     # Specifies the maximum time that an instance should live before
>     # it should be retired and removed from use.  This will happen
>     # gracefully.  Useful for situations where bean instances are
>     # designed to hold potentially expensive resources such as memory
>     # or file handles and need to be periodically cleared out.
>     #
>     # Usable time units: nanoseconds, microsecons, milliseconds,
>     # seconds, minutes, hours, days.  Or any combination such as
>     # "1 hour and 27 minutes and 10 seconds"
>     MaxAge = 0 hours
>     # Applies to MaxAge usage and would rarely be changed, but is a
>     # nice feature to understand.
>     #
>     # When the container first starts and the pool is filled to the
>     # minimum size, all those "minimum" instances will have the same
>     # creation time and therefore all expire at the same time dictated
>     # by the MaxAge setting.  To protect against this sudden drop
>     # scenario and provide a more gradual expiration from the start
>     # the container will spread out the age of the instances that fill
>     # the pool to the minimum using an offset.
>     #
>     # The MaxAgeOffset is not the final value of the offset, but
>     # rather it is used in creating the offset and allows the
>     # spreading to push the initial ages into the future or into the
>     # past.  The pool is filled at startup as follows:
>     #
>     #  for (int i = 0; i < poolMin; i++) {
>     #    long ageOffset = (maxAge / poolMin * i * maxAgeOffset) % maxAge;
>     #    pool.add(new Bean(), ageOffset));
>     #  }
>     #
>     # The default MaxAgeOffset is -1 which causes the initial
>     # instances in the pool to live a bit longer before expiring.  As
>     # a concrete example, let's say the PoolMin is 4 and the MaxAge is
>     # 100 years.  The generated offsets for the four instances created
>     # at startup would be 0, -25, -50, -75.  So the first instance
>     # would be "born" at age 0, die at 100, living 100 years.  The
>     # second instance would be born at -25, die at 100, living a total
>     # of 125 years.  The third would live 150 years.  The fourth 175
>     # years.
>     #
>     # A MaxAgeOffset of 1 would cause instances to be "born" older
>     # and therefore die sooner.  Using the same example PoolMin of 4
>     # and MaxAge of 100 years, the life spans of these initial four
>     # instances would be 100, 75, 50, and 25 years respectively.
>     #
>     # A MaxAgeOffset of 0 will cause no "spreading" of the age of the
>     # first instances used to fill the pool to the minimum and these
>     # instances will of course reach their MaxAge at the same time.
>     # It is possible to set to decimal values such as -0.5, 0.5, -1.2,
>     # or 1.2.
>     MaxAgeOffset = -1
>     # Specifies the maximum time that an instance should be allowed to
>     # sit idly in the pool without use before it should be retired and
>     # removed.
>     #
>     # Note that all instances in the pool, excluding the minimum, are
>     # eligible for garbage collection by the virtual machine as per
>     # the rules of java.lang.ref.WeakReference, so the use of an
>     # IdleTimeout is not required to conserve JVM-managed memory or
>     # shrink the pool.
>     #
>     # Usable time units: nanoseconds, microsecons, milliseconds,
>     # seconds, minutes, hours, days.  Or any combination such as
>     # "1 hour and 27 minutes and 10 seconds"
>     IdleTimeout = 0 minutes
>     # The frequency in which the container will sweep the pool and
>     # evict expired instances.  Eviction is how the IdleTimeout,
>     # MaxAge, and pool "flush" functionality is enforced.  Higher
>     # intervals are better.  Expired instances in use while the pool
>     # is swept will still be evicted upon return to the pool.
>     #
>     # Usable time units: nanoseconds, microsecons, milliseconds,
>     # seconds, minutes, hours, days.  Or any combination such as
>     # "1 hour and 27 minutes and 10 seconds"
>     PollInterval = 5 minutes

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.