Please go ahead as you see fit. I am in the middle of moving now and can only process emails.
I am also not sure about the merit of the refactoring anymore. I recall a message casting doubt on this refactoring adventure :) Gary On Dec 20, 2010, at 13:56, "Simone Tripodi" <simone.trip...@gmail.com> wrote: > Hi Gary, > IMHO the optimizations you're proposing are very important and since I > like cooperating with you, I thought was better making aware about > what I'd intend to do :P > If you agree I could start committing the latest modifications, so you > can apply your refactoring later. WDYT? > Have a nice day, all the best, > Simo > > http://people.apache.org/~simonetripodi/ > http://www.99soft.org/ > > > > On Mon, Dec 20, 2010 at 10:41 PM, Gary Gregory > <ggreg...@seagullsoftware.com> wrote: >> 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 >> >> > > --------------------------------------------------------------------- > 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
