Mailing-List: contact dev-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Commons Developers List" <dev@commons.apache.org>
Received-SPF: pass (nike.apache.org: domain of GGregory@seagullsoftware.com
 designates 216.82.250.3 as permitted sender)
From: Gary Gregory <GGregory@seagullsoftware.com>
To: Commons Developers List <dev@commons.apache.org>
CC: Commons Developers List <dev@commons.apache.org>
Subject: Re: [pool] Pool config vs. factory hierarchies.
Thread-Topic: [pool] Pool config vs. factory hierarchies.
Thread-Index: AQHLkJvgiXbpreakMk2QPT4WB6NngZOKkrOQgADqxICAABum/w==
Date: Wed, 1 Dec 2010 13:39:23 +0000
Message-ID: <CDAB9F3B-867A-4F57-914E-65CAB987C211@seagullsoftware.com>
References: 
 <02AA127CD8DCDE48BC7D2DFB6C87083A07DB70FB@nwt-s-mbx2.rocketsoftware.com>
	<AANLkTim25S3GkAYCzxabPnkHa6pg4DzHuNY2HBkw1Yzw@mail.gmail.com>
	<AANLkTikE9ETQ7KatZpc00dBV6GsSuSqkZP4p4-=3Q4sn@mail.gmail.com>
	<AANLkTiku6G0d7NMYAe7H-3+AH7MYEn0ZJqBZ-Ffgw8q+@mail.gmail.com>
	<AANLkTimxMEZ6heqYfNm=qqKyodqU2bfaM4ioaw27VVeE@mail.gmail.com>
	<AANLkTim-5O64QPJXuUuEcACba_A6hZFMy0wyafrXKXBv@mail.gmail.com>
	<4CCC4E23.4080109@gmail.com>
	<AANLkTikoQr+8NBOGurWEBaC8N8RbAxF2S11CafA6gAFY@mail.gmail.com>
	<4CCCC7C1.1030802@gmail.com>
	<02AA127CD8DCDE48BC7D2DFB6C87083A07DC38FB@nwt-s-mbx2.rocketsoftware.com>
	<4CCCE89B.3040200@gmail.com>
	<47827C26-0F66-445B-9FB4-3E84DF41CF84@seagullsoftware.com>
	<4CCE19A0.3050609@gmail.com>	<4CCE1C4F.6050509@apache.org>
	<4CCE20F8.6090604@gmail.com>
	<AANLkTikgvibvoQg0cwWvT5UhdpOg1t1E-ZcJKQ2EyAw4@mail.gmail.com>
	<AANLkTikxzQ34Mc7dUagAGQtzjb_Xu13kM1DekaMFyiXG@mail.gmail.com>
	<4CD0C204.3020905@gmail.com>
	<AANLkTi=z6BSvLB3AbcdNrKSLHOBkRa7FSqV=qasBu4XA@mail.gmail.com>
	<AANLkTikT0W3Gc6aCD=sfCd7q9MPp3run71u+pPuoFosS@mail.gmail.com>
	<FD39232E-2989-4DA1-896E-5ABCF9E4A70E@gmail.com>
	<AANLkTik6wLNDCBJX_QB=wVC=Th5jo-6hSO6ampcpp5kO@mail.gmail.com>
	<02AA127CD8DCDE48BC7D2DFB6C87083A07DE7A71@nwt-s-mbx2.rocketsoftware.com>,<AANLkTini_sYqZpiBji21J=k6Mfz0+Dr8H+36ydz7hrBq@mail.gmail.com>
In-Reply-To: <AANLkTini_sYqZpiBji21J=k6Mfz0+Dr8H+36ydz7hrBq@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

On Dec 1, 2010, at 2:01, "Simone Tripodi" <simone.tripodi@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.
>=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 about
> it? Many thanks in advance!
>=20
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.=20

I am not sure if it worth changing these method names (new method and depre=
cated old method) or just writing better javadocs. I would go with an exper=
ts 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
> <GGregory@seagullsoftware.com> wrote:
>> Yes, I thought we were on a roll there! Lots of good discussions and the=
n... quiet. That's OK though. We all get busy. Time to come back and reflec=
t.
>>=20
>> I am still looking for these goals:
>> - Generics released ASAP. I would be OK for a earlier release just to ge=
t 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 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
>>>=20
>>> http://people.apache.org/~simonetripodi/
>>> http://www.99soft.org/
>>>=20
>>>=20
>>>=20
>>> On Wed, Nov 3, 2010 at 11:01 PM, Phil Steitz <phil.steitz@gmail.com> wr=
ote:
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>> On Nov 3, 2010, at 5:03 PM, Steven Siebert <smsiebe@gmail.com> wrote:
>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> You restore the pool fields that used to hold the configuration sett=
ing
>>>>>> properties and leave the getters and setters (for the mutable ones) =
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 e=
ither
>>>>> 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 the
>>> parameters of the ctors.  The GOP class stores the config data in indiv=
idual
>>> 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 t=
o the
>>> ctors and/or factories.
>>>>=20
>>>> Phil
>>>>>=20
>>>>>=20
>>>>>   //mutable configuration values are mutated/accessed from pool insta=
nce
>>>>>   private volatile int mut1;  //probably better to use read/write loc=
ks
>>>>>   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 least no=
t
>>>>> public)
>>>>>    * but would be a convenience for "batch"/atomic changes to configu=
ration
>>>>> values -
>>>>>    * this is possible if we switch from volatile to a r/w locking mec=
hanism
>>>>>   */
>>>>>   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 immutab=
le
>>>>> configuration instance if we're going to copy the values locally for =
(at
>>>>> least) mutability purposes?  I believe the attraction of the immutabl=
e
>>>>> configuration instance was for concurrency issues...but with this mod=
el, 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 each
>>>>> pool/factory started to pile up.  We already identified that inherita=
nce 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)...s=
o this
>>>>> means duplication of synchronization code as well.
>>>>>=20
>>>>> I think I'm falling back to my initial thought on this in that the co=
nfig
>>>>> classes should, IMO, either be mutable (where appropriate) and made t=
hread
>>>>> safe (internally synchronized) to reduce the amount of concurrency wo=
rk
>>>>> 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 quic=
k
>>> 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

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org