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 Sun, 05 Dec 2010 13:27:21 GMT
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
<GGregory@seagullsoftware.com> 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.
>>
>> 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
>> <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
>
>

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


Mime
View raw message