On 10/30/10 12:56 PM, Phil Steitz wrote:
On 10/29/10 2:41 PM, James Carman wrote:
On Fri, Oct 29, 2010 at 2:24 PM, sebb<seb...@gmail.com> wrote:
I had overlooked that aspect ...
If some changes are more expensive to perform, then the method might
want to determine which items have changed, rather than just
reconfiguring everything.
There may be some changes that don't require a pool update.
Right now, it appears that they just call that "allocate" method
which
seems like they kind of "nuke and pave", so I don't think it's that
big of a deal.
Factory reconfig probably just needs to update the stored config
variable, which can be volatile.
I'm not familiar with this factory config stuff. I'll have to dig
in further.
Sorry to be late on this. Here are the requirements:
1. Some subset of the config properties (need to decide this -
should be topic of a different thread) need to be *individually*
mutable at runtime - e.g., setMaxActive(newMaxActive) needs to
remain. We have agreed at this point that at least maxActive and
maxWait need to be runtime mutable.
2. Correct functioning of the pool with the current implementation
requires that no thread can change maxActive while another thread
holds the lock on the pool's monitor. Just making the properties
volatile or protecting them with another lock will cause problems.
I am OK keeping the mutable Config instances around, but I don't see
any real advantage to eliminating the member variables storing pool
config properties - i.e., my preference would be to make the Config
instances immutable and only used as structs for ctors.
I am +0 on adding a (pool-synchronized) reconfigure(Config) to
enable multiple properties to be changed atomically.
Sorry, I guess I need to say "-0" here because it now occurs to me
that since Config will include non-runtime mutable properties,
reconfigure(Config) is a little smelly.
Phil
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
