commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Gregory <GGreg...@seagullsoftware.com>
Subject RE: [pool] Pool config vs. factory hierarchies.
Date Wed, 01 Dec 2010 14:21:41 GMT
> -----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

Mime
View raw message