You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Phil Steitz <ph...@gmail.com> on 2010/11/01 02:36:32 UTC
Re: [pool] Pool config vs. factory hierarchies.
On 10/31/10 12:38 AM, Gary Gregory wrote:
> On Oct 31, 2010, at 8:55, "Phil Steitz"<ph...@gmail.com> wrote:
>
>> On 10/30/10 10:55 PM, Gary Gregory wrote:
>>>> -----Original Message----- From: Phil Steitz
>>>> [mailto:phil.steitz@gmail.com] Sent: Sunday, October 31, 2010
>>>> 06:35 To: Commons Developers List Subject: Re: [pool] Pool
>>>> config vs. factory hierarchies.
>>>>
>>>> On 10/30/10 2:30 PM, Simone Tripodi wrote:
>>>>> Hi Phil, the benefits of eliminating the member variables in
>>>>> favor of storing pool config reference are IMHO in therms of
>>>>> code maintainability and keep it as much simple as possible.
>>>>
>>>> Maybe I am being dense here, but I don't quite get that. The
>>>> pool has properties such as numActive that it needs to maintain
>>>> as well as the config-related properties. Keeping the Config
>>>> instance around as a new pool property adds complexity and
>>>> doesn't really improve maintainability, as far as I can see;
>>>> but it is quite possible I am missing something.
>>>
>>> I do not think anyone is being dense here ;) This conversation is
>>> revealing to me that what the pool concepts I have in my head
>>> might be based on incorrect assumptions.
>>>
>>> When I initially saw the long list of ivars (13 or so I think)
>>> that GOP and GKOP had in common, that duplication jumped out to
>>> me as duplication. This is the initial issue I was trying to
>>> resolve. It turns out that the 'fix' for that also leaked to the
>>> config classes.
>>>
>>> As this thread goes on, it /sounds like/ that the GOP and GKOP
>>> are really completely different beasts, which justify what
>>> /appears/ like duplication. Here, it would help to have ivars and
>>> methods renamed to the best possible names, which would remove
>>> the appearance of duplication.
>>
>> +1 to look carefully at the full list of member fields and exposed properties of the GOP and GKOP and decide which ones to rename in GKOP and which ones to drop or redefine.
>
> Who can do this asap so we can see and understand our pile better ?
Well, all are welcome to dig in and form opinions. It is important
that we get the new API right, so I encourage everyone to do that.
Here is how I see things now.
GOP has the following properties (see javadoc in the 1.x code for
full descriptions)
numActive
numIdle
maxActive
maxIdle
minIdle
maxWait
whenExhaustedAction
minEvictableIdleTimeMillis
softMinEvictableIdleTimeMillis
testOnBorrow
testOnReturn
testWhileIdle
timeBetweenEvictionRunsMillis
numTestsPerEvictionRun
lifo
factory
The first two are initialized at 0 and are read-only. All of the
others are read/write with default values. We have decided to
deprecate the setter for the factory property and we have not
decided yet which others should be non-final. Here is my suggested
list of properties that should be runtime mutable:
maxTotal, maxWait, maxIdle, minIdle, idleTimeout, softIdleTimeout
I propose that we rename maxActive to maxTotal, since the name is
confusing, as it really represents the limit on the total number of
object instances (idle or "active") under management by the pool.
While maxActive does in fact limit numActive, they actually measure
different things, so the names should be different. The others
should be obvious.
GKOP has all of the above properties, but adds
maxTotal
and has parameterized properties
numIdle(key)
numActive(key)
maxActive, maxIdle, minIdle are binding per key.
I propose for GKOP
s/maxActive/maxTotalPerKey
s/maxIdle/maxIdlePerKey
s/minIdle/minIdlePerKey
A radical idea that I have been considering is to propose that we
dispense with keyed pools altogether. The DBCP need can be met
without them (see jdbc-pool) and I often ask why it is worth the
bother maintaining GKOP when users can just manage their own
concurrent maps of GOPs. I guess there is some value to the
maintenance and active/idle accounting across pools; but sometimes I
wonder...
Phil
>
>>>
>>> But I do not buy the completely different beasts argument 100%
>>> because the GKOP pool feels related to the GOP.
>>
>> They are not completely unrelated, but the differences are in the core methods both of the pools and their associated object factories.
>>>
>>> It would be possible for example, that the GOP subclass GKOP as a
>>> degenerate simple case where the GOP has one pool in a GKOP. That
>>> seems radical, but it would eliminate a lot of apparent code
>>> duplication: public class AltGenericObjectPool<T> extends
>>> GenericKeyedObjectPool<T, T>. That would be weird in the sense
>>> that APIs like borrowObject() and borrowObject(T) would be
>>> available but you get the idea.
>>
>> I understand the reasoning here, but I don't see it as natural and it would be hard to implement efficiently (at least I don't see an easy way to do it). Here again, I could be missing something that would make this easy.
>>
>
> Maybe it's another strategy that could plugged in that would give the pool a keyed vs not behavior.
>
>>> Finally, if GOP and GKOP are really separate classes not meant to
>>> share code, then should go back to ivars instead of a config
>>> object in each pool?
>>
>> I like replacing all of the vars in the ctors with Config instances.
>
> +1. I dislike classes with laundry lists of cries.
>
>> What I am not sure adds value is keeping the Config instances as members of the pool classes
>
> It might be interesting from the pov of being able to answer succinctly: here is how I was configured. But you could do the same by creating a new config object and answering it.
>
>>
>> I don't like having to maintain similar code in GOP and GKOP and as we think about how to bring in the jdbc-pool stuff, I would like to see if we can reduce the amount of similar code in these two classes, or even if there is a way to somehow combine them efficiently, so I am open to ideas like above.
>
> That is my ideal goal : efficient combo.
>
> GG
>>
>> Phil
>>>
>>> Gary
>>>
>>>>
>>>>>
>>>>> You can see the difference between the current
>>>>> Stack(Keyed)ObjectPool(Factory) - which are implemented
>>>>> according your vision - and Generic(Keyed)ObjectPool(Factory)
>>>>> implementations - that are still implemented with my first
>>>>> refactory.
>>>>
>>>> No, these have the same new complexity (vis a vis the original
>>>> code) and I am not seeing what the benefit is. Keeping the
>>>> pool properties as member fields, making the Config objects
>>>> immutable and just having the ctors copy properties from the
>>>> immutable Config instances (which are then thrown away) seems
>>>> simpler and no harder to maintain to me. Again, I must be
>>>> missing something.
>>>>
>>>> I guess at the end of the day, I don't see the "Config"
>>>> abstraction as adding anything post-construction - i.e,, this
>>>> abstraction is only useful at pool construction time. From the
>>>> user perspective, the config properties are no different from
>>>> any other pool properties, nor are they different internally.
>>>> Why should we need to write Config.maxActive internally, but
>>>> just use numActive and other properties directly? This looks
>>>> to me like added complexity that does not add any value, at
>>>> least for the pools. It makes more sense to me for the
>>>> factories to hold a reference to a Config instance.
>>>>
>>>> Phil
>>>>
>>>>>
>>>>>
>>>>> On Sat, Oct 30, 2010 at 6:56 PM, Phil
>>>>> Steitz<ph...@gmail.com> wrote:
>>>>>> On 10/29/10 2:41 PM, James Carman wrote:
>>>>>>>
>>>>>>> On Fri, Oct 29, 2010 at 2:24 PM, sebb<se...@gmail.com>
>>>>>>> wrote:
>>>>>>>>
>>>>>>>> I had overlooked that aspect ...
>>>>>>>>
>>>>>>>> If some changes are more expensive to perform, then the
>>>>>>>> method might want to determine which items have
>>>>>>>> changed, rather than just reconfiguring everything.
>>>>>>>> There may be some changes that don't require a pool
>>>>>>>> update.
>>>>>>>>
>>>>>>>
>>>>>>> Right now, it appears that they just call that "allocate"
>>>>>>> method which seems like they kind of "nuke and pave", so
>>>>>>> I don't think it's that big of a deal.
>>>>>>>
>>>>>>>> Factory reconfig probably just needs to update the
>>>>>>>> stored config variable, which can be volatile.
>>>>>>>>
>>>>>>>
>>>>>>> I'm not familiar with this factory config stuff. I'll
>>>>>>> have to dig in further.
>>>>>>
>>>>>> Sorry to be late on this. Here are the requirements:
>>>>>>
>>>>>> 1. Some subset of the config properties (need to decide
>>>>>> this - should be topic of a different thread) need to be
>>>>>> *individually* mutable at runtime - e.g.,
>>>>>> setMaxActive(newMaxActive) needs to remain. We have agreed
>>>>>> at this point that at least maxActive and maxWait need to
>>>>>> be runtime mutable.
>>>>>>
>>>>>> 2. Correct functioning of the pool with the current
>>>>>> implementation requires that no thread can change maxActive
>>>>>> while another thread holds the lock on the pool's monitor.
>>>>>> Just making the properties volatile or protecting them with
>>>>>> another lock will cause problems.
>>>>>>
>>>>>> I am OK keeping the mutable Config instances around, but I
>>>>>> don't see any real advantage to eliminating the member
>>>>>> variables storing pool config properties - i.e., my
>>>>>> preference would be to make the Config instances immutable
>>>>>> and only used as structs for ctors.
>>>>>>
>>>>>> I am +0 on adding a (pool-synchronized) reconfigure(Config)
>>>>>> to enable multiple properties to be changed atomically.
>>>>>>
>>>>>> Phil
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>>
>>>>>>>
>> 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
>>
>
> ---------------------------------------------------------------------
> 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
Re: [pool] Pool config vs. factory hierarchies.
Posted by Steven Siebert <sm...@gmail.com>.
That makes sense. I'll provide uniqueness through a property on the
ObjectName (UUID) and discoverability though the domain name if a name is
provided (so it will be easily apparent in the management system). A
resultant ObjectName like:
domain=[optionalProvidedName||org.apache.commons.pool.poolType]:uuid=[uuidValue]
Sound good?
Thanks for the feedback!
S
On Wed, Nov 3, 2010 at 12:04 PM, James Carman <ja...@carmanconsulting.com>wrote:
> On Wed, Nov 3, 2010 at 11:51 AM, Steven Siebert <sm...@gmail.com> wrote:
> > I considered this, but the problem would be finding/viewing the specific
> > pool in the JMX management app (ie jconsole). A GUID gives us
> uniqueness,
> > but it doesn't give us the descriptive name. This has to do with
> ObjectName
> > given when registering the MBean...
> >
>
> Just don't rely on the name as the uniqueness. I'd say have both.
> Use the UUID to determine exactly which one you're talking about, but
> use the name when displaying it to the user.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [pool] Pool config vs. factory hierarchies.
Posted by James Carman <ja...@carmanconsulting.com>.
On Wed, Nov 3, 2010 at 11:51 AM, Steven Siebert <sm...@gmail.com> wrote:
> I considered this, but the problem would be finding/viewing the specific
> pool in the JMX management app (ie jconsole). A GUID gives us uniqueness,
> but it doesn't give us the descriptive name. This has to do with ObjectName
> given when registering the MBean...
>
Just don't rely on the name as the uniqueness. I'd say have both.
Use the UUID to determine exactly which one you're talking about, but
use the name when displaying it to the user.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [pool] Pool config vs. factory hierarchies.
Posted by Steven Siebert <sm...@gmail.com>.
I considered this, but the problem would be finding/viewing the specific
pool in the JMX management app (ie jconsole). A GUID gives us uniqueness,
but it doesn't give us the descriptive name. This has to do with ObjectName
given when registering the MBean...
On Wed, Nov 3, 2010 at 11:12 AM, James Carman <ja...@carmanconsulting.com>wrote:
> On Wed, Nov 3, 2010 at 11:09 AM, Steven Siebert <sm...@gmail.com> wrote:
> > Something I have been considering is the how to represent multiple pools
> in
> > a JVM. I'm thinking we'll need to add an additional optional
> configuration
> > value "poolName" (or something similar) so the MBean will be uniquely
> named
> > and discoverable in the management agent/system. Since it would be
> > optional, if one isn't provided it would default to a 1-up incremented
> name
> > (ie. GOP-1, GOP-2...)
> >
>
> Just assign each pool a UUID.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [pool] Pool config vs. factory hierarchies.
Posted by James Carman <ja...@carmanconsulting.com>.
On Wed, Nov 3, 2010 at 11:09 AM, Steven Siebert <sm...@gmail.com> wrote:
> Something I have been considering is the how to represent multiple pools in
> a JVM. I'm thinking we'll need to add an additional optional configuration
> value "poolName" (or something similar) so the MBean will be uniquely named
> and discoverable in the management agent/system. Since it would be
> optional, if one isn't provided it would default to a 1-up incremented name
> (ie. GOP-1, GOP-2...)
>
Just assign each pool a UUID.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [pool] Pool config vs. factory hierarchies.
Posted by Simone Tripodi <si...@gmail.com>.
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
<GG...@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
>> <GG...@seagullsoftware.com> wrote:
>> > On Dec 1, 2010, at 2:01, "Simone Tripodi" <si...@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
>> >> <GG...@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 <ph...@gmail.com>
>> wrote:
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>> On Nov 3, 2010, at 5:03 PM, Steven Siebert <sm...@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
RE: [pool] Pool config vs. factory hierarchies.
Posted by Gary Gregory <GG...@seagullsoftware.com>.
> -----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
> <GG...@seagullsoftware.com> wrote:
> > On Dec 1, 2010, at 2:01, "Simone Tripodi" <si...@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
> >> <GG...@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 <ph...@gmail.com>
> wrote:
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>> On Nov 3, 2010, at 5:03 PM, Steven Siebert <sm...@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
Re: [pool] Pool config vs. factory hierarchies.
Posted by Simone Tripodi <si...@gmail.com>.
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
<GG...@seagullsoftware.com> wrote:
> On Dec 1, 2010, at 2:01, "Simone Tripodi" <si...@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
>> <GG...@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 <ph...@gmail.com> wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Nov 3, 2010, at 5:03 PM, Steven Siebert <sm...@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
Re: [pool] Pool config vs. factory hierarchies.
Posted by Gary Gregory <GG...@seagullsoftware.com>.
On Dec 1, 2010, at 2:01, "Simone Tripodi" <si...@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
> <GG...@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 <ph...@gmail.com> wrote:
>>>>
>>>>
>>>>
>>>>
>>>> On Nov 3, 2010, at 5:03 PM, Steven Siebert <sm...@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
Re: [pool] Pool config vs. factory hierarchies.
Posted by Simone Tripodi <si...@gmail.com>.
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!
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
<GG...@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 <ph...@gmail.com> wrote:
>> >
>> >
>> >
>> >
>> > On Nov 3, 2010, at 5:03 PM, Steven Siebert <sm...@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
RE: [pool] Pool config vs. factory hierarchies.
Posted by Gary Gregory <GG...@seagullsoftware.com>.
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 <ph...@gmail.com> wrote:
> >
> >
> >
> >
> > On Nov 3, 2010, at 5:03 PM, Steven Siebert <sm...@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
Re: [pool] Pool config vs. factory hierarchies.
Posted by Simone Tripodi <si...@gmail.com>.
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 <ph...@gmail.com> wrote:
>
>
>
>
> On Nov 3, 2010, at 5:03 PM, Steven Siebert <sm...@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
Re: [pool] Pool config vs. factory hierarchies.
Posted by Phil Steitz <ph...@gmail.com>.
On Nov 3, 2010, at 5:03 PM, Steven Siebert <sm...@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
Re: [pool] Pool config vs. factory hierarchies.
Posted by Steven Siebert <sm...@gmail.com>.
>
>
> 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;
//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
Re: [pool] Pool config vs. factory hierarchies.
Posted by Phil Steitz <ph...@gmail.com>.
On 11/3/10 11:09 AM, Steven Siebert wrote:
> Hi Phil,
>
>
>> I caught up on the messages, and I agree with Gary as well. What can I do
>>> to help at this point? I think the group decided to implement immutable
>>> configuration classes...the pools would provide a reference in the
>>> pools/factories and sync/reconfigure with the reconfigure()? Is this
>>> right?
>>>
>>
>> I think the config classes either need to be mutable (as they are now in
>> trunk for GOP) so the individual properties remain *individually* mutable or
>> - my preference - they are immutable and used only by the ctors and they are
>> not used to proxy changes to the pool properties.
>>
>>
>> One consideration with this is mutability of JMX, each individual change
>>> though this interface would call reconfigure().
>>>
>>
>> -1 for forcing that.
>>
>> I also prefer an immutable configuration instance referenced by the
> pool/factory instances....if only to simplify the concurrency. Under your
> preferred model, where the immutable configuration instance is only
> available to the pool/factory instances, how would you recommend going about
> achieving runtime mutability of a pools configuration values (both via JMX
> and programmatically)? I must be missing something....=)
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
>
>
>> +1 for MBean exposing properties. See my last post on what properties
>> should be mutable.
>>
>> Looks great! I think if we can hash out the mutability aspects, JMX
> implementation would be quite easy.
>
> Something I have been considering is the how to represent multiple pools in
> a JVM. I'm thinking we'll need to add an additional optional configuration
> value "poolName" (or something similar) so the MBean will be uniquely named
> and discoverable in the management agent/system. Since it would be
> optional, if one isn't provided it would default to a 1-up incremented name
> (ie. GOP-1, GOP-2...)
>
> Regards,
>
> S
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [pool] Pool config vs. factory hierarchies.
Posted by Steven Siebert <sm...@gmail.com>.
Hi Phil,
> I caught up on the messages, and I agree with Gary as well. What can I do
>> to help at this point? I think the group decided to implement immutable
>> configuration classes...the pools would provide a reference in the
>> pools/factories and sync/reconfigure with the reconfigure()? Is this
>> right?
>>
>
> I think the config classes either need to be mutable (as they are now in
> trunk for GOP) so the individual properties remain *individually* mutable or
> - my preference - they are immutable and used only by the ctors and they are
> not used to proxy changes to the pool properties.
>
>
> One consideration with this is mutability of JMX, each individual change
>> though this interface would call reconfigure().
>>
>
> -1 for forcing that.
>
> I also prefer an immutable configuration instance referenced by the
pool/factory instances....if only to simplify the concurrency. Under your
preferred model, where the immutable configuration instance is only
available to the pool/factory instances, how would you recommend going about
achieving runtime mutability of a pools configuration values (both via JMX
and programmatically)? I must be missing something....=)
> +1 for MBean exposing properties. See my last post on what properties
> should be mutable.
>
> Looks great! I think if we can hash out the mutability aspects, JMX
implementation would be quite easy.
Something I have been considering is the how to represent multiple pools in
a JVM. I'm thinking we'll need to add an additional optional configuration
value "poolName" (or something similar) so the MBean will be uniquely named
and discoverable in the management agent/system. Since it would be
optional, if one isn't provided it would default to a 1-up incremented name
(ie. GOP-1, GOP-2...)
Regards,
S
Re: [pool] Pool config vs. factory hierarchies.
Posted by Phil Steitz <ph...@gmail.com>.
On 11/2/10 10:05 AM, Steven Siebert wrote:
> Hey all,
>
> Sorry I've been away from the discussion, I was stuck in a building with no
> windows for the last week (quite literally) and had very little time to
> breath. At ApacheCon now, so have a bit of time to hack.
>
> I caught up on the messages, and I agree with Gary as well. What can I do
> to help at this point? I think the group decided to implement immutable
> configuration classes...the pools would provide a reference in the
> pools/factories and sync/reconfigure with the reconfigure()? Is this right?
I think the config classes either need to be mutable (as they are
now in trunk for GOP) so the individual properties remain
*individually* mutable or - my preference - they are immutable and
used only by the ctors and they are not used to proxy changes to the
pool properties.
> One consideration with this is mutability of JMX, each individual change
> though this interface would call reconfigure().
-1 for forcing that.
Now, I don't think there
> would be frequent, sweeping, changes...so this probably won't be a huge
> issue. If we're going this route, JMX is a non-issue with this (just
> confirming this). Each pool would implement a MBean that would "expose" the
> configuration settings as well as the pool-specific values (numWaiting, etc)
> for read-only. If this is good with the group, I look forward to
> helping/completing this so I can finalize a patch for the JMX =)
+1 for MBean exposing properties. See my last post on what
properties should be mutable.
Phil
>
> S
>
> On Tue, Nov 2, 2010 at 3:33 AM, Simone Tripodi<si...@gmail.com>wrote:
>
>> Hi all, Phil,
>> thanks for the explanations, very appreciated, I join Gary on saying
>> that maybe my thoughts on Pool are based on incorrect assumptions.
>> Assembling thought from various email and this thread IMHO starts
>> being a little difficult, If we could resume all that thoughts in a
>> wiki page I can take care on refactoring the code to see the design in
>> action.
>> WDYT?
>> Have a nice day,
>> Simo
>>
>> http://people.apache.org/~simonetripodi/
>> http://www.99soft.org/
>>
>>
>>
>> On Mon, Nov 1, 2010 at 3:07 AM, Phil Steitz<ph...@gmail.com> wrote:
>>> On 10/31/10 9:47 PM, Mark Thomas wrote:
>>>>
>>>> On 31/10/2010 21:36, Phil Steitz wrote:
>>>>>
>>>>> A radical idea that I have been considering is to propose that we
>>>>> dispense with keyed pools altogether. The DBCP need can be met without
>>>>> them (see jdbc-pool)
>>>>
>>>> Can it? I know there are some things that DBCP can do that jdbc-pool
>>>> can't such as https://issues.apache.org/bugzilla/show_bug.cgi?id=49543
>>>>
>>>> I thought keyed pools were required for that but I haven't given it much
>>>> more than about 10s thought so I could be wrong.
>>>
>>> For SharedPoolDataSource the way it is currently implemented, yes; but
>>> similar to the statement cache, that class does not use anywhere near the
>>> full features of GKOP. It does not allow you to provide a pre-configure
>> GKOP
>>> or support cross-pool maintenance. The only thing it really needs is
>>> maxTotal enforcement and a map of GOPs. I guess having GKOP means you
>> could
>>> make SPDS more full-featured, but I wonder if its not overkill.
>>>
>>> Probably best to keep it around if we can find a simple performant way to
>>> maintain it.
>>>
>>> Phil
>>>
>>>
>>>>
>>>> Mark
>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> 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
Re: [pool] Pool config vs. factory hierarchies.
Posted by Steven Siebert <sm...@gmail.com>.
Hey all,
Sorry I've been away from the discussion, I was stuck in a building with no
windows for the last week (quite literally) and had very little time to
breath. At ApacheCon now, so have a bit of time to hack.
I caught up on the messages, and I agree with Gary as well. What can I do
to help at this point? I think the group decided to implement immutable
configuration classes...the pools would provide a reference in the
pools/factories and sync/reconfigure with the reconfigure()? Is this right?
One consideration with this is mutability of JMX, each individual change
though this interface would call reconfigure(). Now, I don't think there
would be frequent, sweeping, changes...so this probably won't be a huge
issue. If we're going this route, JMX is a non-issue with this (just
confirming this). Each pool would implement a MBean that would "expose" the
configuration settings as well as the pool-specific values (numWaiting, etc)
for read-only. If this is good with the group, I look forward to
helping/completing this so I can finalize a patch for the JMX =)
S
On Tue, Nov 2, 2010 at 3:33 AM, Simone Tripodi <si...@gmail.com>wrote:
> Hi all, Phil,
> thanks for the explanations, very appreciated, I join Gary on saying
> that maybe my thoughts on Pool are based on incorrect assumptions.
> Assembling thought from various email and this thread IMHO starts
> being a little difficult, If we could resume all that thoughts in a
> wiki page I can take care on refactoring the code to see the design in
> action.
> WDYT?
> Have a nice day,
> Simo
>
> http://people.apache.org/~simonetripodi/
> http://www.99soft.org/
>
>
>
> On Mon, Nov 1, 2010 at 3:07 AM, Phil Steitz <ph...@gmail.com> wrote:
> > On 10/31/10 9:47 PM, Mark Thomas wrote:
> >>
> >> On 31/10/2010 21:36, Phil Steitz wrote:
> >>>
> >>> A radical idea that I have been considering is to propose that we
> >>> dispense with keyed pools altogether. The DBCP need can be met without
> >>> them (see jdbc-pool)
> >>
> >> Can it? I know there are some things that DBCP can do that jdbc-pool
> >> can't such as https://issues.apache.org/bugzilla/show_bug.cgi?id=49543
> >>
> >> I thought keyed pools were required for that but I haven't given it much
> >> more than about 10s thought so I could be wrong.
> >
> > For SharedPoolDataSource the way it is currently implemented, yes; but
> > similar to the statement cache, that class does not use anywhere near the
> > full features of GKOP. It does not allow you to provide a pre-configure
> GKOP
> > or support cross-pool maintenance. The only thing it really needs is
> > maxTotal enforcement and a map of GOPs. I guess having GKOP means you
> could
> > make SPDS more full-featured, but I wonder if its not overkill.
> >
> > Probably best to keep it around if we can find a simple performant way to
> > maintain it.
> >
> > Phil
> >
> >
> >>
> >> Mark
> >>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> 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
>
>
Re: [pool] Pool config vs. factory hierarchies.
Posted by Simone Tripodi <si...@gmail.com>.
Hi all, Phil,
thanks for the explanations, very appreciated, I join Gary on saying
that maybe my thoughts on Pool are based on incorrect assumptions.
Assembling thought from various email and this thread IMHO starts
being a little difficult, If we could resume all that thoughts in a
wiki page I can take care on refactoring the code to see the design in
action.
WDYT?
Have a nice day,
Simo
http://people.apache.org/~simonetripodi/
http://www.99soft.org/
On Mon, Nov 1, 2010 at 3:07 AM, Phil Steitz <ph...@gmail.com> wrote:
> On 10/31/10 9:47 PM, Mark Thomas wrote:
>>
>> On 31/10/2010 21:36, Phil Steitz wrote:
>>>
>>> A radical idea that I have been considering is to propose that we
>>> dispense with keyed pools altogether. The DBCP need can be met without
>>> them (see jdbc-pool)
>>
>> Can it? I know there are some things that DBCP can do that jdbc-pool
>> can't such as https://issues.apache.org/bugzilla/show_bug.cgi?id=49543
>>
>> I thought keyed pools were required for that but I haven't given it much
>> more than about 10s thought so I could be wrong.
>
> For SharedPoolDataSource the way it is currently implemented, yes; but
> similar to the statement cache, that class does not use anywhere near the
> full features of GKOP. It does not allow you to provide a pre-configure GKOP
> or support cross-pool maintenance. The only thing it really needs is
> maxTotal enforcement and a map of GOPs. I guess having GKOP means you could
> make SPDS more full-featured, but I wonder if its not overkill.
>
> Probably best to keep it around if we can find a simple performant way to
> maintain it.
>
> Phil
>
>
>>
>> Mark
>>
>>
>>
>> ---------------------------------------------------------------------
>> 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
Re: [pool] Pool config vs. factory hierarchies.
Posted by Phil Steitz <ph...@gmail.com>.
On 10/31/10 9:47 PM, Mark Thomas wrote:
> On 31/10/2010 21:36, Phil Steitz wrote:
>> A radical idea that I have been considering is to propose that we
>> dispense with keyed pools altogether. The DBCP need can be met without
>> them (see jdbc-pool)
>
> Can it? I know there are some things that DBCP can do that jdbc-pool
> can't such as https://issues.apache.org/bugzilla/show_bug.cgi?id=49543
>
> I thought keyed pools were required for that but I haven't given it much
> more than about 10s thought so I could be wrong.
For SharedPoolDataSource the way it is currently implemented, yes;
but similar to the statement cache, that class does not use anywhere
near the full features of GKOP. It does not allow you to provide a
pre-configure GKOP or support cross-pool maintenance. The only thing
it really needs is maxTotal enforcement and a map of GOPs. I guess
having GKOP means you could make SPDS more full-featured, but I
wonder if its not overkill.
Probably best to keep it around if we can find a simple performant
way to maintain it.
Phil
>
> Mark
>
>
>
> ---------------------------------------------------------------------
> 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
Re: [pool] Pool config vs. factory hierarchies.
Posted by Mark Thomas <ma...@apache.org>.
On 31/10/2010 21:36, Phil Steitz wrote:
> A radical idea that I have been considering is to propose that we
> dispense with keyed pools altogether. The DBCP need can be met without
> them (see jdbc-pool)
Can it? I know there are some things that DBCP can do that jdbc-pool
can't such as https://issues.apache.org/bugzilla/show_bug.cgi?id=49543
I thought keyed pools were required for that but I haven't given it much
more than about 10s thought so I could be wrong.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org