commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <phil.ste...@gmail.com>
Subject Re: [pool] Pool config vs. factory hierarchies.
Date Sat, 30 Oct 2010 16:56:03 GMT
On 10/29/10 2:41 PM, James Carman wrote:
> On Fri, Oct 29, 2010 at 2:24 PM, sebb<sebbaz@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.

Phil


>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message