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
