commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steven Siebert <>
Subject Re: [pool] Pool config vs. factory hierarchies.
Date Wed, 03 Nov 2010 15:09:59 GMT
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....=)

> +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...)



  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message