Ok. Think I'm totally done with all our new fancy stateless pooling
options. We only had three before: PoolSize, AccessTimeout,
StrictPooling.
Here is the full set.
# Specifies the time an invokation should wait for an instance
# of the pool to become available.
#
# After the timeout is reached, if an instance in the pool cannot
# be obtained, the method invocation will fail.
#
# Usable time units: nanoseconds, microsecons, milliseconds,
# seconds, minutes, hours, days. Or any combination such as
# "1 hour and 27 minutes and 10 seconds"
AccessTimeout = 0 milliseconds
# 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 size of the bean pools for this stateless
# SessionBean container. If StrictPooling is not used, instances
# will still be created beyond this number if there is demand, but
# they will not be returned to the pool and instead will be
# immediately destroyed.
PoolSize 10
# StrictPooling tells the container what to do when the pool
# reaches it's maximum size and there are incoming requests that
# need instances.
#
# With strict pooling, requests will have to wait for instances to
# become available. The pool size will never grow beyond the the
# set PoolSize value. The maximum amount of time a request should
# wait is specified via the AccessTimeout setting.
#
# Without strict pooling, the container will create temporary
# instances to meet demand. The instances will last for just one
# method invocation and then are removed.
#
# Setting StrictPooling to false and PoolSize to 0 will result in
# no pooling. Instead instances will be created on demand and live
# for exactly one method call before being removed.
StrictPooling true
# 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
# When sweeping the pool for expired instances a thread pool is
# used to process calling @PreDestroy on expired instances as well
# as creating new instances as might be required to fill the pool
# to the minimum after a Flush or MaxAge expiration. The
# CallbackThreads setting dictates the size of the thread pool and
# is shared by all beans deployed in the container.
CallbackThreads = 5
