commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Phil Steitz (JIRA)" <j...@apache.org>
Subject [jira] Reopened: (POOL-173) Better config without duplication.
Date Sun, 07 Nov 2010 23:40:08 GMT

     [ https://issues.apache.org/jira/browse/POOL-173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Phil Steitz reopened POOL-173:
------------------------------

      Assignee:     (was: Simone Tripodi)

Here is a patch showing how we can use the Config encapsulation while maintaining granular
control of pool properties.  The patch is against trunk and only shows changes to GOP.  If
the approach is acceptable, we can extend to GKOP.   I did not rename properties or reduce
mutability per discussions on commons-dev.  That would be a logical next step.

> Better config without duplication.
> ----------------------------------
>
>                 Key: POOL-173
>                 URL: https://issues.apache.org/jira/browse/POOL-173
>             Project: Commons Pool
>          Issue Type: Improvement
>            Reporter: Gary Gregory
>            Priority: Minor
>             Fix For: 2.0
>
>         Attachments: commons-pool2-configExisting.dia, commons-pool2-configExisting.png,
pool173-better_config_without_duplication.diff, pool2config.diff
>
>
> There is code duplication in configuration code.
> I'd like to track an experiment here.
> > -----Original Message-----
> > From: Gary Gregory [mailto:GGregory@seagullsoftware.com]
> > Sent: Wednesday, October 20, 2010 10:44
> > To: Commons Developers List
> > Subject: RE: [pool] Reusing Config
> > 
> > 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/>
> > >
> > 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message