commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steven Siebert <smsi...@gmail.com>
Subject Re: [pool] Reusing Config
Date Mon, 25 Oct 2010 14:51:03 GMT
Simo,

You make a good point, especially with the groupId/package change.

POOL-169 did implement some deprecations for changes from 1.5 to 2.0, so
this isn't without precedent and consistency (even for the sake of
consistency in commons-* subprojects, IMO) is important.  Honestly, I could
go either way...just wanted to make sure it was considered =)

S

On Mon, Oct 25, 2010 at 10:02 AM, Simone Tripodi
<simone.tripodi@gmail.com>wrote:

> Hi Steven :)
> thanks for the explanation, as far as I understand there are a lot of
> things I can learn from you about JMX so I started feeling impatient
> to see your commits :P
>
> I don't think we should mark with @Deprecate removed ctors, classes
> are now living in a fresh new package so, as user, I wouldn't expect
> retro-compatibility at all. When upgrading a major revision, I expect
> a completely (or partially, in that case) new version of the
> library... maybe I'm wrong but my instinct suggests me a 2.0 version
> could be even a completely rewrite of the 1.5.
> BTW that's just my opinion :P
>
> Have a nice day,
> Simo
>
> http://people.apache.org/~simonetripodi/
> http://www.99soft.org/
>
>
>
> On Mon, Oct 25, 2010 at 3:51 PM, Steven Siebert <smsiebe@gmail.com> wrote:
> > Simone,
> >
> > I'm sorry I'm confusing, so many thoughts going though my mind =)
> >
> > yes, I think the best approach is to provide a separate class for the
> > JMX...but I'm thinking that doing a private inner class (non-static) in
> each
> > pool would be the cleanest way to do so.  This way, the MBean (instance)
> > would have direct access to both the config values (read/write) as well
> as
> > the ability to invoke pool methods (such as getNumwaiters(), POOL-159).
> > This would significantly cut down on the bootstrapping of having to
> register
> > the config and pool with the MBean.
> >
> > Once I get home, I'll attach a JMX patch to POOL-172 using your latest
> > commit.
> >
> > I noticed your two JIRA tickets for the concurrency and builder
> > pattern....should one be submitted to add the @deprecated tag to the 1.5
> API
> > for the various classes, methods, and constructors we're blowing away?
> >
> > On Mon, Oct 25, 2010 at 9:30 AM, Simone Tripodi <
> simone.tripodi@gmail.com>wrote:
> >
> >> Hi Steven,
> >> very sorry to have missed the Jira notifications, just checked now
> >> after read your email. Sorry! :(
> >>
> >> I thought the idea was adding JMX support directly on factory/pool and
> >> not on Configuration, btw not being JMX expert this will be a good
> >> chance to learn... I'll fill a new Jira issue for adding thread safety
> >> support on configuration classes, and start to study how to do it in
> >> the best way.
> >>
> >> I like the Builder idea, my +1 for that, take it in consideration as
> >> already done :P
> >>
> >> Have a nice day and thanks for the feedbacks!
> >> Simo
> >>
> >> http://people.apache.org/~simonetripodi/<
> http://people.apache.org/%7Esimonetripodi/>
> >> http://www.99soft.org/
> >>
> >>
> >>
> >> On Mon, Oct 25, 2010 at 3:06 PM, Steven Siebert <smsiebe@gmail.com>
> wrote:
> >> > Hi Simone,
> >> >
> >> > You have two +1's waiting for you in the JIRA comments =)
> >> >
> >> > My comments from tracker:
> >> >
> >> > "I took a look at this last night but didn't get a chance to comment
> =)
> >> >
> >> > I like the patch, I believe this does indeed satisfy the issue.
> >> >
> >> > One question I have, since we're eliminating the primitive
> configuration
> >> > properties within the pool/factory classes, we're making the Config
> >> objects
> >> > publicly accessible, and possibly accessing through JMX is the idea of
> >> > making the Config objects thread-safe. This would certainly reduce the
> >> need
> >> > to have to externally synchronize (and possibly introduce bugs) every
> >> time.
> >> >
> >> > Another issue we probably need to open another ticket for is to
> deprecate
> >> > the constructors we've eliminated in 1.5.
> >> >
> >> > Last suggestion/question is about making inner (public static final)
> >> Builder
> >> > pattern classes within the concrete Config classes (and possibly
> defining
> >> an
> >> > abstract <T extends Abstract*Config> create() method in the Abstract
> >> class).
> >> > This would further simplify the programmatic creation of the Config
> >> classes.
> >> >
> >> > Thoughts?
> >> >
> >> > +1 on Simones patch...we can add any of the above after it has been
> >> > committed."
> >> >
> >> >
> >> > Respectfully,
> >> >
> >> >
> >> > Steve
> >> >
> >> >
> >> >
> >> > On Mon, Oct 25, 2010 at 8:36 AM, Simone Tripodi <
> >> simone.tripodi@gmail.com>wrote:
> >> >
> >> >> Hi all mates,
> >> >> I updated the jira issue uploading my patch; it contains the
> >> >> configuration extraction and some code modification.
> >> >> IMHO we shouldn't replicate the same data in both configuration AND
> >> >> factory/pool, when creating the factory/pool it is enough storing the
> >> >> configuration reference, just use it.
> >> >> I intentionally missed the interfaces layer, since they can be added
> >> >> directly in the JMX support in the required form.
> >> >> Please take a look at the patch and provide feedbacks, if you agree
I
> >> >> could start committing the modifications and proceed on JMX support.
> >> >> Have a nice day,
> >> >> Simo
> >> >>
> >> >> http://people.apache.org/~simonetripodi/<
> http://people.apache.org/%7Esimonetripodi/>
> >> <http://people.apache.org/%7Esimonetripodi/>
> >> >> http://www.99soft.org/
> >> >>
> >> >>
> >> >>
> >> >> On Fri, Oct 22, 2010 at 5:23 AM, Gary Gregory
> >> >> <GGregory@seagullsoftware.com> wrote:
> >> >> >> -----Original Message-----
> >> >> >> From: Steven Siebert [mailto:smsiebe@gmail.com]
> >> >> >> Sent: Thursday, October 21, 2010 18:08
> >> >> >> To: Commons Developers List
> >> >> >> Subject: Re: [pool] Reusing Config
> >> >> >>
> >> >> >> Gary,
> >> >> >>
> >> >> >> Great work so far.  I'm checking out the diffs now, I'm gonna
hack
> >> out
> >> >> some
> >> >> >> simple UML "diffs", if only to wrap my head around it all.
I'll
> >> upload
> >> >> the
> >> >> >> file to the issue once complete.
> >> >> >>
> >> >> >> BTW, I hope I didn't offend with the 'academic' comment, I
> >> >> >> most certainly did not intend to infer that there weren't
> functional
> >> >> >> importances to this issue.  I was mostly trying to delineate
the
> two
> >> >> issues
> >> >> >> in my mind, and putting it to "paper" was a good way to do
that =)
> >> >> >>
> >> >> >> Cheers,
> >> >> >>
> >> >> >> S
> >> >> >
> >> >> > Hi Steven,
> >> >> >
> >> >> > No offense even considered from this end :)
> >> >> >
> >> >> > I'm glad we are going through this exercise. This will improve
the
> >> >> software I am sure.
> >> >> >
> >> >> > Gary
> >> >> >
> >> >> >>
> >> >> >>
> >> >> >> On Thu, Oct 21, 2010 at 3:35 PM, Gary Gregory
> >> >> >> <GGregory@seagullsoftware.com>wrote:
> >> >> >>
> >> >> >> > > -----Original Message-----
> >> >> >> > > From: Phil Steitz [mailto:phil.steitz@gmail.com]
> >> >> >> > > Sent: Thursday, October 21, 2010 06:29
> >> >> >> > > To: Commons Developers List
> >> >> >> > > Subject: Re: [pool] Reusing Config
> >> >> >> > >
> >> >> >> > > On 10/21/10, Simone Tripodi <simone.tripodi@gmail.com>
wrote:
> >> >> >> > > > 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
> >> >> >> > > >
> >> >> >> > >
> >> >> >> > > Sorry I have been a little slow on this.  I will
have a
> careful
> >> look
> >> >> >> > > this eve.  Based on a very quick review, I am +1
on the idea
> and
> >> >> >> > > approach to separate mutable / immutable.  Also
+1 for JMX
> >> support.
> >> >> >> > > Two quick things to keep top of mind:
> >> >> >> > >
> >> >> >> > > 1.  Please make sure not to lose documentation.
 Whatever is
> >> >> >> > > documented today in protected field / internal getters
/
> setters
> >> >> docs
> >> >> >> > > needs to be carried forward.
> >> >> >> >
> >> >> >> > Check. I did not check as I refactored that Javadocs
were in the
> >> right
> >> >> >> > places. That would be a requirement for a real patch.
I only
> meant
> >> >> this as
> >> >> >> > an experiment that went a lot further than I thought.
> >> >> >> >
> >> >> >> > >
> >> >> >> > > 2. Somewhat related - I am fine just plowing ahead
for now
> using
> >> >> >> > > existing API concepts, but some of those concepts
are
> >> anachronistic
> >> >> or
> >> >> >> > > broken, IMO, so we may later decide to revamp much
of the
> >> >> "accounting"
> >> >> >> > > aspects of the  API.  That we should and will discuss
on other
> >> >> >> > > threads.  One thing that might be good to think
about at this
> >> point,
> >> >> >> > > however, is getting rid of primitive properties
(we started
> that
> >> >> with
> >> >> >> > > whenExhaustedAction).  I think there is a DBCP issue
on this
> >> raised
> >> >> by
> >> >> >> > > Dain a couple of years ago.
> >> >> >> >
> >> >> >> > It would be nice to track this someplace, I am not sure
if
> Javadoc
> >> is
> >> >> the
> >> >> >> > right place.
> >> >> >> >
> >> >> >> > Gary
> >> >> >> >
> >> >> >> > >
> >> >> >> > > Thanks all for moving this along!
> >> >> >> > >
> >> >> >> > > Phil
> >> >> >> > > > http://people.apache.org/~simonetripodi/<
> http://people.apache.org/%7Esimonetripodi/>
> >> <http://people.apache.org/%7Esimonetripodi/>
> >> >> >> > > > 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://people.apache.org/%7Esimonetripodi/>
> >> <http://people.apache.org/%7Esimonetripodi/>
> >> >> >> > > >>> 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://people.apache.org/%7Esimonetripodi/>
> >> <http://people.apache.org/%7Esimonetripodi/>
> >> >> >> > > >>> >> 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://people.apache.org/%7Esimonetripodi/>
> >> <http://people.apache.org/%7Esimonetripodi/>
> >> >> >> > > >>> >> >> 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://people.apache.org/%7Esimonetripodi/>
> >> <http://people.apache.org/%7Esimonetripodi/>
> >> >> >> > > >>> >> >> >> 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
> >> >> >> > > >
> >> >> >> > > >
> >> >> >> > >
> >> >> >> > >
> >> >> ---------------------------------------------------------------------
> >> >> >> > > 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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message