> -----Original Message----- > From: Simone Tripodi [mailto:simone.trip...@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 > <ggreg...@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: ggreg...@seagullsoftware.com > > Web: seagull.rocketsoftware.com > > > > > > > >> -----Original Message----- > >> From: Simone Tripodi [mailto:simone.trip...@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 > >> <ggreg...@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: ggreg...@seagullsoftware.com > >> > Web: seagull.rocketsoftware.com > >> > > >> > > >> > > >> >> -----Original Message----- > >> >> From: Simone Tripodi [mailto:simone.trip...@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 > >> >> <ggreg...@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.trip...@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 > >> >> >> <ggreg...@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: ggreg...@seagullsoftware.com > >> >> >>> Web: seagull.rocketsoftware.com > >> >> >>> > >> >> >>> > >> >> >>> > >> >> >>>> -----Original Message----- > >> >> >>>> From: Gary Gregory [mailto:ggreg...@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: > >> ggreg...@seagullsoftware.com<mailto:ggreg...@seagullsoftware.com> > >> >> >>>> Web: > >> seagull.rocketsoftware.com<http://www.seagull.rocketsoftware.com/> > >> >> >>>> > >> >> >>> > >> >> >>> > >> >> >>> -------------------------------------------------------------------- > - > >> >> >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > >> >> >>> For additional commands, e-mail: dev-h...@commons.apache.org > >> >> >>> > >> >> >>> > >> >> >> > >> >> >> --------------------------------------------------------------------- > >> >> >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > >> >> >> For additional commands, e-mail: dev-h...@commons.apache.org > >> >> >> > >> >> > > >> >> > --------------------------------------------------------------------- > >> >> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > >> >> > For additional commands, e-mail: dev-h...@commons.apache.org > >> >> > > >> >> > > >> >> > >> >> --------------------------------------------------------------------- > >> >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > >> >> For additional commands, e-mail: dev-h...@commons.apache.org > >> > > >> > > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > >> For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org
