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<smsi...@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.trip...@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<smsi...@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.trip...@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
<ggreg...@seagullsoftware.com> wrote:
-----Original Message-----
From: Steven Siebert [mailto:smsi...@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
<ggreg...@seagullsoftware.com>wrote:
-----Original Message-----
From: Phil Steitz [mailto:phil.ste...@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.trip...@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
<ggreg...@seagullsoftware.com> wrote:
-----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://people.apache.org/%7Esimonetripodi/>
<http://people.apache.org/%7Esimonetripodi/>
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://people.apache.org/%7Esimonetripodi/>
<http://people.apache.org/%7Esimonetripodi/>
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://people.apache.org/%7Esimonetripodi/>
<http://people.apache.org/%7Esimonetripodi/>
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://people.apache.org/%7Esimonetripodi/>
<http://people.apache.org/%7Esimonetripodi/>
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
---------------------------------------------------------------------
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
