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 05:41:21 GMT
Hi Gary!
unfortunately the link replied with 404 code, can you give me please
the issue ID?
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


Mime
View raw message