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...) Regards, S
