commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simone Tripodi <simone.trip...@gmail.com>
Subject Re: [pool] Reusing Config
Date Thu, 21 Oct 2010 09:16:53 GMT
it seems you've been doing a very good work, the only thing I *suggest* is

* simplifying the mutable/immutable interfaces, one interface for
already known common (im)mutable fields should be enough;
* adding/renaming the interfaces with the <PoolName>`MBean` postfix to
be ready for JMX support;

btw it seems you're now much more deep inside the topic than me ;)

WDYT?
Simo

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



On Thu, Oct 21, 2010 at 8:23 AM, Gary Gregory
<GGregory@seagullsoftware.com> wrote:
>> -----Original Message-----
>> From: Simone Tripodi [mailto:simone.tripodi@gmail.com]
>> Sent: Wednesday, October 20, 2010 22:41
>> To: Commons Developers List
>> Subject: Re: [pool] Reusing Config
>>
>> Hi Gary!
>> unfortunately the link replied with 404 code, can you give me please
>> the issue ID?
>
> It's https://issues.apache.org/jira/browse/POOL-173
>
> I've updated the diff file a couple of times since my initial msg.
>
> Gary
>
>> Many thanks in advance, have a nice day!!!
>> Simo
>>
>> http://people.apache.org/~simonetripodi/
>> http://www.99soft.org/
>>
>>
>>
>> On Thu, Oct 21, 2010 at 12:16 AM, Gary Gregory
>> <GGregory@seagullsoftware.com> wrote:
>> > Hi Simone,
>> >
>> > Please see my experiment in progress here
>> https://issues.apache.org/jira/secure/attachment/12457710/pool2config.diff
>> >
>> > Gary Gregory
>> > Senior Software Engineer
>> > Rocket Software
>> > 3340 Peachtree Road, Suite 820 • Atlanta, GA 30326 • USA
>> > Tel: +1.404.760.1560
>> > Email: ggregory@seagullsoftware.com
>> > Web: seagull.rocketsoftware.com
>> >
>> >
>> >
>> >> -----Original Message-----
>> >> From: Simone Tripodi [mailto:simone.tripodi@gmail.com]
>> >> Sent: Wednesday, October 20, 2010 14:53
>> >> To: Commons Developers List
>> >> Subject: Re: [pool] Reusing Config
>> >>
>> >> Hi,
>> >> sorry for not having been clear, but in my previous email my intent
>> >> was saying that depending on how we manage the Config class, it could
>> >> influence de JMX support design, nothing more, and since I'm not
>> >> expert on JMX I was waiting for feedbacks from who knows more than me
>> >>
>> >> About Gary's question, I had the following thought
>> >>
>> >> AbstractGenericObjectPoolConfig
>> >> - int maxIdle
>> >> - int minIdle
>> >> - int maxActive
>> >> - long maxWait
>> >> - WhenExhaustedAction whenExhaustedAction
>> >> - boolean testOnBorrow
>> >> - boolean testOnReturn
>> >> - boolean testWhileIdle
>> >> - long timeBetweenEvictionRunsMillis
>> >> - int numTestsPerEvictionRun
>> >> - long minEvictableIdleTimeMillis
>> >> - boolean lifo
>> >>
>> >> GenericObjectPoolConfig extends AbstractGenericObjectPoolConfig
>> >> - long softMinEvictableIdleTimeMillis
>> >>
>> >> GenericKeyedObjectPoolConfig extends GenericObjectPoolConfig
>> >> - int maxTotal
>> >>
>> >> About the pools:
>> >>
>> >> class GenericObjectPool {
>> >>   + GenericObjectPool(GenericObjectPoolFactory factory) {
>> >>       this(factory, new GenericObjectPoolConfig());
>> >>   }
>> >>
>> >>   + GenericObjectPool(GenericObjectPoolFactory factory,
>> >> GenericObjectPoolConfig config) {...}
>> >>
>> >>   + GenericObjectPoolConfig getConfig() {...}
>> >> }
>> >>
>> >> same thing for the Keyed version.
>> >>
>> >> Too simple and stupid? Maybe. But reduces the redundancies to 0.
>> >> Moreover I'm not sure it is just an academical way to approach the
>> >> issue, I'm sure it is more than pragmatic, simplifying the
>> >> maintainability and makes easier keep in synch the Pool and related
>> >> Factory configuration.
>> >> Just my 2 cents, now off to bed due my local timezone :P
>> >> Simo
>> >>
>> >> http://people.apache.org/~simonetripodi/
>> >> http://www.99soft.org/
>> >>
>> >>
>> >>
>> >> On Wed, Oct 20, 2010 at 10:40 PM, Gary Gregory
>> >> <GGregory@seagullsoftware.com> wrote:
>> >> > So I am doing an experimental refactoring to see what the code would
look
>> >> like with a Config class extracted and I ran into the following.
>> >> >
>> >> > The class GenericObjectPool has an _softMinEvictableIdleTimeMillis
ivar
>> but
>> >> the equivalent GenericKeyedObjectPool does not.
>> >> >
>> >> > Is that a little hole in implementation that could have been avoided
with
>> a
>> >> common classes used for config? Even if GenericKeyedObjectPool would throw
>> a
>> >> "not implemented" exception.
>> >> >
>> >> > Thoughts?
>> >> >
>> >> > Gary Gregory
>> >> > Senior Software Engineer
>> >> > Rocket Software
>> >> > 3340 Peachtree Road, Suite 820 • Atlanta, GA 30326 • USA
>> >> > Tel: +1.404.760.1560
>> >> > Email: ggregory@seagullsoftware.com
>> >> > Web: seagull.rocketsoftware.com
>> >> >
>> >> >
>> >> >
>> >> >> -----Original Message-----
>> >> >> From: Simone Tripodi [mailto:simone.tripodi@gmail.com]
>> >> >> Sent: Wednesday, October 20, 2010 12:22
>> >> >> To: Commons Developers List
>> >> >> Subject: Re: [pool] Reusing Config
>> >> >>
>> >> >> sure, I always wait for feedbacks before coding :P Cool expression
>> >> >> "Rambo through the code", that was the first time I read it and
made
>> >> >> me laugh :D
>> >> >> All the best,
>> >> >> Simo
>> >> >>
>> >> >> http://people.apache.org/~simonetripodi/
>> >> >> http://www.99soft.org/
>> >> >>
>> >> >>
>> >> >>
>> >> >> On Wed, Oct 20, 2010 at 9:17 PM, Gary Gregory
>> >> >> <GGregory@seagullsoftware.com> wrote:
>> >> >> > It seems to me there is a reason the code is the way it is
so I'd
>> really
>> >> >> like to hear thoughts from some of the original authors before
we go and
>> >> Rambo
>> >> >> through the code ;)
>> >> >> >
>> >> >> > Gary
>> >> >> >
>> >> >> > On Oct 20, 2010, at 12:13, "Simone Tripodi" <simone.tripodi@gmail.com>
>> >> >> wrote:
>> >> >> >
>> >> >> >> Hi Gary,
>> >> >> >> yes that's me that raised the question[1] and discussed
a little with
>> >> >> >> Seb. What blocked me was the JMX support proposal since
I'm not
>> >> >> >> familiar with that technology, so I was consulting documentation
to
>> >> >> >> study.
>> >> >> >>
>> >> >> >> My very big +1 for that, with the wish of work directly
on that
>> stuff.
>> >> >> >> Anyone else has a different thought, before proceeding?
>> >> >> >> Thanks in advance,
>> >> >> >> Simo
>> >> >> >>
>> >> >> >> [1] http://markmail.org/message/q4y7ghux57s7hk6v
>> >> >> >>
>> >> >> >> http://people.apache.org/~simonetripodi/
>> >> >> >> http://www.99soft.org/
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >> >> On Wed, Oct 20, 2010 at 7:43 PM, Gary Gregory
>> >> >> >> <GGregory@seagullsoftware.com> wrote:
>> >> >> >>> In the same department, I see the following ivars:
>> >> >> >>>
>> >> >> >>> lifo : boolean
>> >> >> >>> maxActive : int
>> >> >> >>> maxIdle : int
>> >> >> >>> maxTotal : int
>> >> >> >>> maxWait : long
>> >> >> >>> minEvictableIdleTimeMillis : long
>> >> >> >>> minIdle : int
>> >> >> >>> numTestsPerEvictionRun : int
>> >> >> >>> testOnBorrow : boolean
>> >> >> >>> testOnReturn : boolean
>> >> >> >>> testWhileIdle : boolean
>> >> >> >>> timeBetweenEvictionRunsMillis : long
>> >> >> >>> whenExhaustedAction : WhenExhaustedAction
>> >> >> >>>
>> >> >> >>> defined in four classes:
>> >> >> >>>
>> >> >> >>> GenericKeyedObjectPool
>> >> >> >>> GenericKeyedObjectPoolFactory
>> >> >> >>> GenericObjectPool
>> >> >> >>> GenericObjectPoolFactory
>> >> >> >>>
>> >> >> >>> Which feels to me like a missed opportunity to avoid
duplication.
>> >> >> >>>
>> >> >> >>> Is making one ivar private or final or volatile be
applied to all
>> four
>> >> >> classes?
>> >> >> >>>
>> >> >> >>> We could:
>> >> >> >>>
>> >> >> >>> Use a config object instead of the 13 ivars.
>> >> >> >>> Or a common superclass then we can consider if it
should hold the
>> ivar
>> >> >> list or a Config object.
>> >> >> >>>
>> >> >> >>> Would it be too weird to have a common super class
for
>> BaseObjectPool
>> >> and
>> >> >> BasePoolableObjectFactory for example?
>> >> >> >>>
>> >> >> >>> Gary Gregory
>> >> >> >>> Senior Software Engineer
>> >> >> >>> Rocket Software
>> >> >> >>> 3340 Peachtree Road, Suite 820 . Atlanta, GA 30326
. USA
>> >> >> >>> Tel: +1.404.760.1560
>> >> >> >>> Email: ggregory@seagullsoftware.com
>> >> >> >>> Web: seagull.rocketsoftware.com
>> >> >> >>>
>> >> >> >>>
>> >> >> >>>
>> >> >> >>>> -----Original Message-----
>> >> >> >>>> From: Gary Gregory [mailto:GGregory@seagullsoftware.com]
>> >> >> >>>> Sent: Wednesday, October 20, 2010 10:29
>> >> >> >>>> To: Commons Developers List
>> >> >> >>>> Subject: [pool] Reusing Config
>> >> >> >>>>
>> >> >> >>>> Hi All:
>> >> >> >>>>
>> >> >> >>>> I think this came up recently. Any thoughts or
plans on extracting
>> the
>> >> >> Config
>> >> >> >>>> class out of GenericKeyedObjectPool and GenericObjectPool
so it can
>> be
>> >> >> reused.
>> >> >> >>>> The constants for default values could then also
be moved to
>> Config.
>> >> >> >>>> Gary Gregory
>> >> >> >>>> Senior Software Engineer
>> >> >> >>>> Rocket Software
>> >> >> >>>> 3340 Peachtree Road, Suite 820 * Atlanta, GA 30326
* USA
>> >> >> >>>> Tel: +1.404.760.1560
>> >> >> >>>> Email:
>> >> ggregory@seagullsoftware.com<mailto:ggregory@seagullsoftware.com>
>> >> >> >>>> Web:
>> >> seagull.rocketsoftware.com<http://www.seagull.rocketsoftware.com/>
>> >> >> >>>>
>> >> >> >>>
>> >> >> >>>
>> >> >> >>> --------------------------------------------------------------------
>> -
>> >> >> >>> 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


Mime
View raw message