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 <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
