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
