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
