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 Wed, 03 Nov 2010 19:20:50 GMT
On 11/3/10 11:09 AM, Steven Siebert wrote:
> Hi Phil,
>> I caught up on the messages, and I agree with Gary as well.  What can I do
>>> to help at this point?  I think the group decided to implement immutable
>>> configuration classes...the pools would provide a reference in the
>>> pools/factories and sync/reconfigure with the reconfigure()?  Is this
>>> right?
>> I think the config classes either need to be mutable (as they are now in
>> trunk for GOP) so the individual properties remain *individually* mutable or
>> - my preference - they are immutable and used only by the ctors and they are
>> not used to proxy changes to the pool properties.
>>    One consideration with this is mutability of JMX, each individual change
>>> though this interface would call reconfigure().
>> -1 for forcing that.
>> I also prefer an immutable configuration instance referenced by the
> pool/factory instances....if only to simplify the concurrency.  Under your
> preferred model, where the immutable configuration instance is only
> available to the pool/factory instances, how would you recommend going about
> achieving runtime mutability of a pools configuration values (both via JMX
> and programmatically)?  I must be missing something....=)

You restore the pool fields that used to hold the configuration 
setting properties and leave the getters and setters (for the 
mutable ones) in place.

>> +1 for MBean exposing properties.  See my last post on what properties
>> should be mutable.
>> Looks great!  I think if we can hash out the mutability aspects, JMX
> implementation would be quite easy.
> Something I have been considering is the how to represent multiple pools in
> a JVM.  I'm thinking we'll need to add an additional optional configuration
> value "poolName" (or something similar) so the MBean will be uniquely named
> and discoverable in the management agent/system.  Since it would be
> optional, if one isn't provided it would default to a 1-up incremented name
> (ie. GOP-1, GOP-2...)
> Regards,
> S

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

View raw message