commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <>
Subject Re: [pool] Pool config vs. factory hierarchies.
Date Sat, 30 Oct 2010 17:28:03 GMT
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<> 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
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message