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.
Phil
+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: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
