Still had some bugs in the Pool and PoolTest classes. Found them
while hammering on other code as some of the tests would fail
"randomly". Check out this for the details:
http://svn.apache.org/viewvc?view=revision&revision=929931
If you see any of these tests fail, definitely post.
-David
On Mar 25, 2010, at 2:14 AM, David Blevins wrote:
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
