> -----Original Message----- > From: Simone Tripodi [mailto:simone.trip...@gmail.com] > Sent: Wednesday, December 01, 2010 08:51 > To: Commons Developers List > Subject: Re: [pool] Pool config vs. factory hierarchies. > > Hi Gary, > yes, more people involved on defining these details is better, I > agree. I'm thinking about creating a wiki page to resume all the > requirements, what do you think?
Good idea! Gary > Simo > > http://people.apache.org/~simonetripodi/ > http://www.99soft.org/ > > > > On Wed, Dec 1, 2010 at 2:39 PM, Gary Gregory > <ggreg...@seagullsoftware.com> wrote: > > On Dec 1, 2010, at 2:01, "Simone Tripodi" <simone.trip...@gmail.com> wrote: > > > >> Hi Gary :) > >> thanks for the feedback, IMHO once the Configuration for > >> Generic(Keyed)ObjectPool(Factory) will be fixed, we could start > >> thinking about a new release of the new pool. This evening/tonight (in > >> my local time) I'll start re-arranging stuff, of course suggestions > >> will be more than appreciated. > >> > >> About duplication: I agree with you, but after re-reading all the > >> mails we wrote about it, I recently become convinced that > >> Configuration for GKOB/GOB have different semantic even if some > >> configuration property have same name/type, what's your opinion about > >> it? Many thanks in advance! > >> > > Yes, semantics are different iirc and I'd confusing is that some props have > the same name but mean different things for each pool type. > > > > I am not sure if it worth changing these method names (new method and > deprecated old method) or just writing better javadocs. I would go with an > experts opinion there. > > > > Gary > >> Have a nice day, > >> Simo > >> > >> http://people.apache.org/~simonetripodi/ > >> http://www.99soft.org/ > >> > >> > >> > >> On Tue, Nov 30, 2010 at 11:02 PM, Gary Gregory > >> <ggreg...@seagullsoftware.com> wrote: > >>> Yes, I thought we were on a roll there! Lots of good discussions and > then... quiet. That's OK though. We all get busy. Time to come back and > reflect. > >>> > >>> I am still looking for these goals: > >>> - Generics released ASAP. I would be OK for a earlier release just to get > this out. > >>> - Better names for properties and methods > >>> - Refactor to remove duplication > >>> > >>> Gary > >>> > >>>> -----Original Message----- > >>>> From: Simone Tripodi [mailto:simone.trip...@gmail.com] > >>>> Sent: Tuesday, November 30, 2010 09:33 > >>>> To: Commons Developers List > >>>> Subject: Re: [pool] Pool config vs. factory hierarchies. > >>>> > >>>> Hi all guys, > >>>> sorry for resurrecting a zombie message, but I've been busy at work > >>>> and haven't had the chance to contribute at all. > >>>> I could re-start committing code according to the requirements > >>>> described by Phil, If it works for you, so other tasks like > >>>> JMX/autoconfigure can be unlocked, please let me know. > >>>> Have a nice day, > >>>> Simo > >>>> > >>>> http://people.apache.org/~simonetripodi/ > >>>> http://www.99soft.org/ > >>>> > >>>> > >>>> > >>>> On Wed, Nov 3, 2010 at 11:01 PM, Phil Steitz <phil.ste...@gmail.com> > wrote: > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> On Nov 3, 2010, at 5:03 PM, Steven Siebert <smsi...@gmail.com> wrote: > >>>>> > >>>>>>> > >>>>>>> > >>>>>>> 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 > >>>>>>> > >>>>>>> > >>>>>> so something like this? > >>>>>> > >>>>>> public class GOP extends .... { > >>>>>> > >>>>>> /** > >>>>>> * ref to immutable config reference, immutable config values are > either > >>>>>> referred directly here > >>>>>> * or are copied to a final instance field > >>>>>> */ > >>>>>> private GOPConfig config > >>>>> > >>>>> No. There is no config member. It is used only to encapsulate the > >>>> parameters of the ctors. The GOP class stores the config data in > individual > >>>> fields, accessed by getters and setters. The setters at least are > >>>> synchronized using the pool monitor. Look at the old code. What I am > >>>> proposing is that we limit the use and lifetime of the config objects to > the > >>>> ctors and/or factories. > >>>>> > >>>>> Phil > >>>>>> > >>>>>> > >>>>>> //mutable configuration values are mutated/accessed from pool > instance > >>>>>> private volatile int mut1; //probably better to use read/write locks > >>>>>> private volatile int mut2; > >>>>>> > >>>>>> public GOP (GOPConfig config) { > >>>>>> this.config = config; > >>>>>> reconfigure(config); > >>>>>> } > >>>>>> > >>>>>> /** > >>>>>> * using this model, this method isn't really required (at least not > >>>>>> public) > >>>>>> * but would be a convenience for "batch"/atomic changes to > configuration > >>>>>> values - > >>>>>> * this is possible if we switch from volatile to a r/w locking > mechanism > >>>>>> */ > >>>>>> public void reconfigure (GOPConfig config) { > >>>>>> mut1 = config.getMut1; > >>>>>> mut2 = config.getMut2; > >>>>>> } > >>>>>> > >>>>>> public void setMut1 (int m) { > >>>>>> mut1 = m; > >>>>>> } > >>>>>> > >>>>>> public int getMut1 () { > >>>>>> return mut1; > >>>>>> } > >>>>>> > >>>>>> .... > >>>>>> } > >>>>>> > >>>>>> I wonder, with this model....what is the reason for having an immutable > >>>>>> configuration instance if we're going to copy the values locally for > (at > >>>>>> least) mutability purposes? I believe the attraction of the immutable > >>>>>> configuration instance was for concurrency issues...but with this > model, we > >>>>>> would need to use pool-local syncronization (locking) anyway. > >>>>>> > >>>>>> I wrote a quick mock-up implementation like this, using a > >>>>>> ReentrantReadWriteLock, and the amount of concurrency work in each > >>>>>> pool/factory started to pile up. We already identified that > inheritance of > >>>>>> the Pool/Factory classes might not be the best approach (I agree with > this > >>>>>> as well...which would cause POOL-177 to no longer be implemented)...so > this > >>>>>> means duplication of synchronization code as well. > >>>>>> > >>>>>> I think I'm falling back to my initial thought on this in that the > config > >>>>>> classes should, IMO, either be mutable (where appropriate) and made > thread > >>>>>> safe (internally synchronized) to reduce the amount of concurrency work > >>>>>> needed in each class that aggregates the instance...or immutable and > any > >>>>>> changes to the config instance needs to be done by going back to the > >>>> Builder > >>>>>> (something like new Builder(configInstance).change().create());) and > then > >>>>>> the config reference in each pool/factory could be made volatile. > >>>>>> > >>>>>> I know this is confusing in email....I would be glad to create a quick > >>>> patch > >>>>>> or UML for this to clear things up if this would help. > >>>>>> > >>>>>> Thoughts? > >>>>>> > >>>>>> S > >>>>> > >>>>> --------------------------------------------------------------------- > >>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > >>>>> For additional commands, e-mail: dev-h...@commons.apache.org > >>>>> > >>>>> > >>>> > >>>> --------------------------------------------------------------------- > >>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > >>>> For additional commands, e-mail: dev-h...@commons.apache.org > >>> > >>> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > >> For additional commands, e-mail: dev-h...@commons.apache.org > >> > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org
