commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simone Tripodi <simone.trip...@gmail.com>
Subject Re: [pool] Pool config vs. factory hierarchies.
Date Wed, 01 Dec 2010 13:50:43 GMT
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?
Simo

http://people.apache.org/~simonetripodi/
http://www.99soft.org/



On Wed, Dec 1, 2010 at 2:39 PM, Gary Gregory
<GGregory@seagullsoftware.com> wrote:
> 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.
>>
>> 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
>> <GGregory@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.tripodi@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.steitz@gmail.com>
wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Nov 3, 2010, at 5:03 PM, Steven Siebert <smsiebe@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-unsubscribe@commons.apache.org
>>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

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


Mime
View raw message