Return-Path: Delivered-To: apmail-commons-dev-archive@www.apache.org Received: (qmail 20858 invoked from network); 20 Dec 2010 21:42:18 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 20 Dec 2010 21:42:18 -0000 Received: (qmail 21088 invoked by uid 500); 20 Dec 2010 21:42:17 -0000 Delivered-To: apmail-commons-dev-archive@commons.apache.org Received: (qmail 20997 invoked by uid 500); 20 Dec 2010 21:42:17 -0000 Mailing-List: contact dev-help@commons.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Commons Developers List" Delivered-To: mailing list dev@commons.apache.org Received: (qmail 20989 invoked by uid 99); 20 Dec 2010 21:42:17 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 20 Dec 2010 21:42:17 +0000 X-ASF-Spam-Status: No, hits=-2.3 required=10.0 tests=RCVD_IN_DNSWL_MED,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of GGregory@seagullsoftware.com designates 216.82.253.19 as permitted sender) Received: from [216.82.253.19] (HELO mail152.messagelabs.com) (216.82.253.19) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 20 Dec 2010 21:42:12 +0000 X-VirusChecked: Checked X-Env-Sender: GGregory@seagullsoftware.com X-Msg-Ref: server-8.tower-152.messagelabs.com!1292881308!18532987!3 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [137.134.240.188] Received: (qmail 22568 invoked from network); 20 Dec 2010 21:41:50 -0000 Received: from unknown (HELO postal.rocketsoftware.com) (137.134.240.188) by server-8.tower-152.messagelabs.com with AES128-SHA encrypted SMTP; 20 Dec 2010 21:41:50 -0000 Received: from NWT-S-MBX1.rocketsoftware.com ([fe80::34fc:6d7f:6837:62b]) by nwt-s-cas1.rocketsoftware.com ([::1]) with mapi id 14.01.0270.001; Mon, 20 Dec 2010 16:41:40 -0500 From: Gary Gregory To: Commons Developers List CC: Commons Developers List Subject: Re: [pool] Refactoring Config classes (Was: [pool] Pool config vs. factory hierarchies.) Thread-Topic: [pool] Refactoring Config classes (Was: [pool] Pool config vs. factory hierarchies.) Thread-Index: AQHLoINm6fiR7jYbp0am65xPTScAQpOp3FiR Date: Mon, 20 Dec 2010 21:41:40 +0000 Message-ID: <9526E164-A386-4049-89C1-E250F9F3CBE1@seagullsoftware.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Don't worry about my stuff. I am in the middle of a move.=20 Gary On Dec 20, 2010, at 12:20, "Simone Tripodi" wrot= e: > 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 >=20 > [1] http://wiki.apache.org/commons/PoolRoadMap >=20 > http://people.apache.org/~simonetripodi/ > http://www.99soft.org/ >=20 >=20 >=20 > On Sun, Dec 5, 2010 at 2:27 PM, Simone Tripodi = 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 >>=20 >> [1] http://wiki.apache.org/commons/PoolRoadMap >>=20 >> http://people.apache.org/~simonetripodi/ >> http://www.99soft.org/ >>=20 >>=20 >>=20 >> On Wed, Dec 1, 2010 at 3:21 PM, Gary Gregory >> wrote: >>>> -----Original Message----- >>>> From: Simone Tripodi [mailto:simone.tripodi@gmail.com] >>>> Sent: Wednesday, December 01, 2010 08:51 >>>> To: Commons Developers List >>>> Subject: Re: [pool] Pool config vs. factory hierarchies. >>>>=20 >>>> 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? >>>=20 >>> Good idea! >>>=20 >>> Gary >>>=20 >>>> Simo >>>>=20 >>>> http://people.apache.org/~simonetripodi/ >>>> http://www.99soft.org/ >>>>=20 >>>>=20 >>>>=20 >>>> On Wed, Dec 1, 2010 at 2:39 PM, Gary Gregory >>>> wrote: >>>>> On Dec 1, 2010, at 2:01, "Simone Tripodi" = wrote: >>>>>=20 >>>>>> 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. >>>>>>=20 >>>>>> 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 abou= t >>>>>> it? Many thanks in advance! >>>>>>=20 >>>>> Yes, semantics are different iirc and I'd confusing is that some prop= s have >>>> the same name but mean different things for each pool type. >>>>>=20 >>>>> 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 wit= h an >>>> experts opinion there. >>>>>=20 >>>>> Gary >>>>>> Have a nice day, >>>>>> Simo >>>>>>=20 >>>>>> http://people.apache.org/~simonetripodi/ >>>>>> http://www.99soft.org/ >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> On Tue, Nov 30, 2010 at 11:02 PM, Gary Gregory >>>>>> wrote: >>>>>>> Yes, I thought we were on a roll there! Lots of good discussions an= d >>>> then... quiet. That's OK though. We all get busy. Time to come back an= d >>>> reflect. >>>>>>>=20 >>>>>>> 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 >>>>>>>=20 >>>>>>> Gary >>>>>>>=20 >>>>>>>> -----Original Message----- >>>>>>>> From: Simone Tripodi [mailto:simone.tripodi@gmail.com] >>>>>>>> Sent: Tuesday, November 30, 2010 09:33 >>>>>>>> To: Commons Developers List >>>>>>>> Subject: Re: [pool] Pool config vs. factory hierarchies. >>>>>>>>=20 >>>>>>>> Hi all guys, >>>>>>>> sorry for resurrecting a zombie message, but I've been busy at wor= k >>>>>>>> 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 >>>>>>>>=20 >>>>>>>> http://people.apache.org/~simonetripodi/ >>>>>>>> http://www.99soft.org/ >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> On Wed, Nov 3, 2010 at 11:01 PM, Phil Steitz >>>> wrote: >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> On Nov 3, 2010, at 5:03 PM, Steven Siebert wr= ote: >>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> You restore the pool fields that used to hold the configuration >>>> setting >>>>>>>>>>> properties and leave the getters and setters (for the mutable o= nes) in >>>>>>>>>>> place. >>>>>>>>>>>=20 >>>>>>>>>>> Phil >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>> so something like this? >>>>>>>>>>=20 >>>>>>>>>> public class GOP extends .... { >>>>>>>>>>=20 >>>>>>>>>> /** >>>>>>>>>> * ref to immutable config reference, immutable config values = are >>>> either >>>>>>>>>> referred directly here >>>>>>>>>> * or are copied to a final instance field >>>>>>>>>> */ >>>>>>>>>> private GOPConfig config >>>>>>>>>=20 >>>>>>>>> No. There is no config member. It is used only to encapsulate t= he >>>>>>>> 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 obje= cts to >>>> the >>>>>>>> ctors and/or factories. >>>>>>>>>=20 >>>>>>>>> Phil >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> //mutable configuration values are mutated/accessed from pool >>>> instance >>>>>>>>>> private volatile int mut1; //probably better to use read/writ= e locks >>>>>>>>>> private volatile int mut2; >>>>>>>>>>=20 >>>>>>>>>> public GOP (GOPConfig config) { >>>>>>>>>> this.config =3D config; >>>>>>>>>> reconfigure(config); >>>>>>>>>> } >>>>>>>>>>=20 >>>>>>>>>> /** >>>>>>>>>> * using this model, this method isn't really required (at lea= st 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 lockin= g >>>> mechanism >>>>>>>>>> */ >>>>>>>>>> public void reconfigure (GOPConfig config) { >>>>>>>>>> mut1 =3D config.getMut1; >>>>>>>>>> mut2 =3D config.getMut2; >>>>>>>>>> } >>>>>>>>>>=20 >>>>>>>>>> public void setMut1 (int m) { >>>>>>>>>> mut1 =3D m; >>>>>>>>>> } >>>>>>>>>>=20 >>>>>>>>>> public int getMut1 () { >>>>>>>>>> return mut1; >>>>>>>>>> } >>>>>>>>>>=20 >>>>>>>>>> .... >>>>>>>>>> } >>>>>>>>>>=20 >>>>>>>>>> I wonder, with this model....what is the reason for having an im= mutable >>>>>>>>>> configuration instance if we're going to copy the values locally= for >>>> (at >>>>>>>>>> least) mutability purposes? I believe the attraction of the imm= utable >>>>>>>>>> configuration instance was for concurrency issues...but with thi= s >>>> model, we >>>>>>>>>> would need to use pool-local syncronization (locking) anyway. >>>>>>>>>>=20 >>>>>>>>>> I wrote a quick mock-up implementation like this, using a >>>>>>>>>> ReentrantReadWriteLock, and the amount of concurrency work in ea= ch >>>>>>>>>> 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. >>>>>>>>>>=20 >>>>>>>>>> I think I'm falling back to my initial thought on this in that t= he >>>> config >>>>>>>>>> classes should, IMO, either be mutable (where appropriate) and m= ade >>>> thread >>>>>>>>>> safe (internally synchronized) to reduce the amount of concurren= cy 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= . >>>>>>>>>>=20 >>>>>>>>>> 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. >>>>>>>>>>=20 >>>>>>>>>> Thoughts? >>>>>>>>>>=20 >>>>>>>>>> S >>>>>>>>>=20 >>>>>>>>> -----------------------------------------------------------------= ---- >>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org >>>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>> ------------------------------------------------------------------= --- >>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org >>>>>>>> For additional commands, e-mail: dev-help@commons.apache.org >>>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>> --------------------------------------------------------------------= - >>>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org >>>>>> For additional commands, e-mail: dev-help@commons.apache.org >>>>>>=20 >>>>>=20 >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org >>>>> For additional commands, e-mail: dev-help@commons.apache.org >>>>>=20 >>>>>=20 >>>>=20 >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org >>>> For additional commands, e-mail: dev-help@commons.apache.org >>>=20 >>>=20 >>=20 >=20 > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org > For additional commands, e-mail: dev-help@commons.apache.org >=20 --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org For additional commands, e-mail: dev-help@commons.apache.org