Don't worry about my stuff. I am in the middle of a move. Gary
On Dec 20, 2010, at 12:20, "Simone Tripodi" <simone.trip...@gmail.com> wrote: > Hi all guys, > I spent the afternoon refactoring the config classes according to > informations collected on[1], have a ready commit. > Do you want to read the patch before I commit or I I can commit so > everybody can review and contribute to the modifications? > This could block the Gary's work on optimization, please let me know! > Thanks in advance, > Simo > > [1] http://wiki.apache.org/commons/PoolRoadMap > > http://people.apache.org/~simonetripodi/ > http://www.99soft.org/ > > > > On Sun, Dec 5, 2010 at 2:27 PM, Simone Tripodi <simone.trip...@gmail.com> > wrote: >> Hi Gary/all :) >> I collected informations on the wiki on the RoadMap page[1], based on >> what we discussed in this thread. >> If you agree on what is written, we can start back coding. >> Have a nice weekend, >> Simo >> >> [1] http://wiki.apache.org/commons/PoolRoadMap >> >> http://people.apache.org/~simonetripodi/ >> http://www.99soft.org/ >> >> >> >> On Wed, Dec 1, 2010 at 3:21 PM, Gary Gregory >> <ggreg...@seagullsoftware.com> wrote: >>>> -----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 >>> >>> >> > > --------------------------------------------------------------------- > 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
