You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Steven Caswell <st...@caswell.name> on 2002/04/23 23:24:39 UTC
[pool] PROPOSAL: add collecting of statistics to pool implementations
Proposal: add collecting of statistics to pool implementations
Reasoning: I'd like to be able to get stats from a pooling
implementation to see how well the various configuration parameters are
set. For example, in the GenericObjectPool implementation, I'd like to
know how many waits occurred, how many times the pool was extended, etc.
Proposed design changes:
- Create an interface called PoolStatistics that defines operations for
obtaining the statistics values and associated labels. Actual values
would be returned in an array of ints. Value labels would be returned in
an array of Strings. This would allow each pool implementation class to
define its own set of statistics and label them accordingly.
- Create an interface called Measurable that would be implemented by a
pool that supports reporting of statistics. This interface defines the
operation that returns an instance of PoolStatistics. Defining a
separate interface allows individual pool implementations to support or
not support reporting statistics at the choosing of the implementor.
I've attached source code for the new PoolStatistics and Measurable
interfaces. I've also attached patches to the GenericObjectPool and
GenericObjectPoolFactory implementation classes that provide a first cut
implementation, and the TestGenericObjectPool test case. I've run the
test cases on these changes and they pass. If this proposal is accepted
in some form I'll be happy to add a first cut implementation to the
other pool implementation classes.
Steven Caswell
steven@caswell.name
Re: [pool] PROPOSAL: add collecting of statistics to pool implementations
Posted by Henri Yandell <ba...@generationjava.com>.
On Fri, 26 Apr 2002, Berin Loritsch wrote:
> You have no imagination. ;P
How can you! I came up with the whole Lego analogy as well. Along with
every other programmer in the world I think.
> In the last case, its easy: mod_webapp is replacing mod_jk.
I'm a consumer in this case, it was all very confusing when I researched
it and needs better docs :)
> > Like having a regulator who walks around the system checking that everyone
> > is still following the initial project plan.
>
> I doubt you will ever get that through the voting process. There are
> too many developers in Jakarta land that oppose strong project
> management.
Yeah, I'm not even sure I'd vote for it. But it does seem like it might
work. Basically a way to raise to the entire project community that a pair
of projects seem to be causing confusion to the consumer. I assume the
committee at the top does that.
> > How does this sound? I guess the actual end result would be that
> > Avalon/Commons would somehow have to display a clear description of how
> > they relate. Ditto for JJAR/Maven.
>
> All that would happen is a bunch of "this project is better because XYZ"
> and there would be little objective data to back up the claims.
I think you're right.
Hen
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [pool] PROPOSAL: add collecting of statistics to pool implementations
Posted by Paulo Gaspar <pa...@krankikom.de>.
> Mod_webapp attempted to replace mod_jk, and AFAIK it didn't even got
> close.
Oh God!
I never expected to see this put in such explicit way! I thought
it was a well kept secret.
=;o)
Anyway, mod_webapp raised the level of ambition on the connectors
and that can only be good for mod_jk too.
Maybe you always had that ambition Costin (and I sure believe so)
but mod_webapp probably helped widening the horizons of others.
Yes, competition is a Good Thing (TM).
=:oD
Have fun,
Paulo Gaspar
> -----Original Message-----
> From: costinm@covalent.net [mailto:costinm@covalent.net]
> Sent: Saturday, April 27, 2002 2:07 AM
> To: Jakarta Commons Developers List
> Subject: Re: [pool] PROPOSAL: add collecting of statistics to pool
> implementations
>
>
> On Fri, 26 Apr 2002, Berin Loritsch wrote:
>
> > > The user sits there and can't discern an immediate difference
> between the
> > > products. mod_webapp/mod_jk is another example.
> >
> > In the last case, its easy: mod_webapp is replacing mod_jk.
>
> Where did you got this ?
>
> Mod_webapp attempted to replace mod_jk, and AFAIK it didn't even got
> close.
>
>
> Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [pool] PROPOSAL: add collecting of statistics to pool implementations
Posted by co...@covalent.net.
On Fri, 26 Apr 2002, Berin Loritsch wrote:
> > The user sits there and can't discern an immediate difference between the
> > products. mod_webapp/mod_jk is another example.
>
> In the last case, its easy: mod_webapp is replacing mod_jk.
Where did you got this ?
Mod_webapp attempted to replace mod_jk, and AFAIK it didn't even got
close.
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [pool] PROPOSAL: add collecting of statistics to pool implementations
Posted by Berin Loritsch <bl...@apache.org>.
Henri Yandell wrote:
>>>My definition of macro vs micro is probably best expressed as giving
>>>someone a lego kit in a box versus giving someone lots of lego bricks. In
>>>the former there is a defined way to build the system, though you can play
>>>with it. In the latter it's entirely up to you.
>>
>>I think that is a good analogy. Although you can still take legos from
>>different kits and come up with new creations. :) I used to do that all
>>the time. In some ways, I still do.
>
>
> And to push the analogy to its bounds, by taking lego from different kits
> you end up with quite an ugly product :) Plus you get all your pieces
> muddled up.
You have no imagination. ;P
Sometimes I came up with something better than any of the kits allowed.
>
> I think that Excalibur/Commons needs to get a good solution in place
> before the consumers get confused. It seems to be a frequent problem in
> Jakarta-land. JSTL/Taglibs and JJAR/Maven also suffer from it.
> The user sits there and can't discern an immediate difference between the
> products. mod_webapp/mod_jk is another example.
In the last case, its easy: mod_webapp is replacing mod_jk.
>
> The Jakarta virus? Duplication. I know sourceforge has this lots, but
> you'd expect it there as you're not dealing with one entity. But Jakarta
> is one entity to the external consumer, so the duplication problem is a
> very poor selling point.
>
> Only solution I can think of is for aggressive management so that when two
> projects appear to be considered duplicate, the two projects must produce
> a plan for how the duplication will be dealt with.
>
> Like having a regulator who walks around the system checking that everyone
> is still following the initial project plan.
I doubt you will ever get that through the voting process. There are
too many developers in Jakarta land that oppose strong project
management.
>
> That would work for JJAR/Maven. They started with very different aims and
> it's happened that a sub-part of Maven and JJAR have the same
> functionality.
>
> For JSTL/Taglibs it wouldn't make sense as it was obvious from the outset
> (probably) that they would clash. In this case I would assume that the
> duplication plan would have to be known from the outset.
>
> How does this sound? I guess the actual end result would be that
> Avalon/Commons would somehow have to display a clear description of how
> they relate. Ditto for JJAR/Maven.
All that would happen is a bunch of "this project is better because XYZ"
and there would be little objective data to back up the claims.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [pool] PROPOSAL: add collecting of statistics to pool implementations
Posted by Henri Yandell <ba...@generationjava.com>.
On Sat, 27 Apr 2002, Paulo Gaspar wrote:
> However, "aggressive management" is NOT a solution. Not even in the
> "corporate world".
I'm happy to accept this. T'was an idea, but not one I've had experience
of trying before.
I'm mainly pushing for some explanation to users as to the differences,
why, what, where etc. But I can't see easy ways to write that explanation
without someone having to have good knowledge of the topics and be
involved with each party.
Another idea; documentation written by all the projects. So there's a page
detailing 'Database connection pooling' and its authored by each group
coding this. Creating a common location where each component can sell
itself.
An important part of code, be it open-source or other, is to be used. I'm
wanting to make it easier to use, by confusing less.
Hen
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [pool] PROPOSAL: add collecting of statistics to pool implementations
Posted by Paulo Gaspar <pa...@krankikom.de>.
Henri,
You even forgot to put Turbine in the equation. There is duplicated
code across the Commons, Avalon AND Turbine.
However, "aggressive management" is NOT a solution. Not even in the
"corporate world".
If you try to choose a winner between 2 or 3 groups you end up with a
war in your hands and many of the losers moving somewhere else since
they do not want to work with something they do not believe on.
Then, you also end up with ONLY the knowledge of the winners.
There is also the problem that it is often not clear which solution
is better for a given problem. Sometimes you need quite some time for
that to become clear.
And often there is more than an ideal tool - it just depends on the
style and believes of the person using the tool.
OTOH, if you help all the groups communicating with each other and
learning from each other:
- A lot of cooperation, exchange of knowledge and other synergies
will spontaneously form;
- "Natural selection" will tend to exclude the worse bits overall;
- Everybody will be happier.
Some Turbine guys are already contributing a lot to the commons and
some Avalon guys too.
I also do not care much about confused users, especially for
development tools. One always gets confused when choosing a tool
anyway, even when it is a commercial tool. Why should Open Source
tools be different.
And then, there are the different styles. Most Avalon users would
never use Turbine and most Turbine users would never use Avalon.
As usual, "aggressive management" would just kill the creativity
and productivity we now have, which I consider quite impressive.
Have fun,
Paulo Gaspar
> -----Original Message-----
> From: Henri Yandell [mailto:bayard@generationjava.com]
> Sent: Friday, April 26, 2002 6:23 PM
>
> ...
>
> And to push the analogy to its bounds, by taking lego from different kits
> you end up with quite an ugly product :) Plus you get all your pieces
> muddled up.
>
> I think that Excalibur/Commons needs to get a good solution in place
> before the consumers get confused. It seems to be a frequent problem in
> Jakarta-land. JSTL/Taglibs and JJAR/Maven also suffer from it.
> The user sits there and can't discern an immediate difference between the
> products. mod_webapp/mod_jk is another example.
>
> The Jakarta virus? Duplication. I know sourceforge has this lots, but
> you'd expect it there as you're not dealing with one entity. But Jakarta
> is one entity to the external consumer, so the duplication problem is a
> very poor selling point.
>
> Only solution I can think of is for aggressive management so that when two
> projects appear to be considered duplicate, the two projects must produce
> a plan for how the duplication will be dealt with.
>
> Like having a regulator who walks around the system checking that everyone
> is still following the initial project plan.
>
> That would work for JJAR/Maven. They started with very different aims and
> it's happened that a sub-part of Maven and JJAR have the same
> functionality.
>
> For JSTL/Taglibs it wouldn't make sense as it was obvious from the outset
> (probably) that they would clash. In this case I would assume that the
> duplication plan would have to be known from the outset.
>
> How does this sound? I guess the actual end result would be that
> Avalon/Commons would somehow have to display a clear description of how
> they relate. Ditto for JJAR/Maven.
>
> Hen
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [pool] PROPOSAL: add collecting of statistics to pool implementations
Posted by Henri Yandell <ba...@generationjava.com>.
> > My definition of macro vs micro is probably best expressed as giving
> > someone a lego kit in a box versus giving someone lots of lego bricks. In
> > the former there is a defined way to build the system, though you can play
> > with it. In the latter it's entirely up to you.
>
> I think that is a good analogy. Although you can still take legos from
> different kits and come up with new creations. :) I used to do that all
> the time. In some ways, I still do.
And to push the analogy to its bounds, by taking lego from different kits
you end up with quite an ugly product :) Plus you get all your pieces
muddled up.
I think that Excalibur/Commons needs to get a good solution in place
before the consumers get confused. It seems to be a frequent problem in
Jakarta-land. JSTL/Taglibs and JJAR/Maven also suffer from it.
The user sits there and can't discern an immediate difference between the
products. mod_webapp/mod_jk is another example.
The Jakarta virus? Duplication. I know sourceforge has this lots, but
you'd expect it there as you're not dealing with one entity. But Jakarta
is one entity to the external consumer, so the duplication problem is a
very poor selling point.
Only solution I can think of is for aggressive management so that when two
projects appear to be considered duplicate, the two projects must produce
a plan for how the duplication will be dealt with.
Like having a regulator who walks around the system checking that everyone
is still following the initial project plan.
That would work for JJAR/Maven. They started with very different aims and
it's happened that a sub-part of Maven and JJAR have the same
functionality.
For JSTL/Taglibs it wouldn't make sense as it was obvious from the outset
(probably) that they would clash. In this case I would assume that the
duplication plan would have to be known from the outset.
How does this sound? I guess the actual end result would be that
Avalon/Commons would somehow have to display a clear description of how
they relate. Ditto for JJAR/Maven.
Hen
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [pool] PROPOSAL: add collecting of statistics to pool implementations
Posted by Berin Loritsch <bl...@apache.org>.
Henri Yandell wrote:
<snip/>
> If Avalon is a macro view made up of micro components, and Commons is
> micro components, when will we hit a stage where we have a redundant
> micro-components project, and how should this be dealt with?
Avalon started as a collection of lessons learned from the Apache JServ
project. It was built to abstract out the common patterns that were in
that project and could be applied to other projects.
A couple of other projects were started to test the theories: Apache
JAMES and Cocoon. Both of those projects have contributed information
back to Avalon that has helped it be better.
As always happens with frameworks (Turbine included) is that it grew
in scope, and the needs it was satisfying. It was no longer a list of
patterns and best practices, but a collection of useful code that could
be used in a number of different packages.
So now Avalon has the framework (aka Framework), micro components (aka
Excalibur), a logger (aka LogKit), macro components (aka Cornerstone),
and a microkernel based server (aka Phoenix).
The most clash that occurs with Commons occurs in the Excalibur package.
I don't recall the whole inception of Commons very well, but I
believe we lobbied unsuccessfully to merge Excalibur and commons before
commons was created. Again I could be wrong on that point. There are
cultural differences between the two communities for sure. That is
one reason for some of the duplication. Another reason is the fact that
the Avalon site is not yet set up to plainly declare what we have,
something that commons is a little better about.
We are working on these issues so that it is easier to find out what
exactly lives in Avalon and what is in Commons. The user of the
software will be able to make an *informed* decision of which project
they want to use.
>
> My definition of macro vs micro is probably best expressed as giving
> someone a lego kit in a box versus giving someone lots of lego bricks. In
> the former there is a defined way to build the system, though you can play
> with it. In the latter it's entirely up to you.
I think that is a good analogy. Although you can still take legos from
different kits and come up with new creations. :) I used to do that all
the time. In some ways, I still do.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [pool] PROPOSAL: add collecting of statistics to pool implementations
Posted by Henri Yandell <ba...@generationjava.com>.
I'd say the reason for the coexistence is the same as for a lot of
components that coexist between Avalon and Commons.
Both projects have a similar mandate. Commons on a micro level, Avalon on
a macro level. These different views seem to create a lot of internal
disagreement between the two projects and a fair amount of politics.
This leads to communication problems with both parties lacking awareness
of what is in the other, and a lot of threads that continue as this one
has [See Berin and Rodney's posts].
>From what little I've gleaned of Avalon [Yep, I'm as guilty as anyone of
not having a clue what the other half is doing] they have been
restructuring the components so that they are more independent of the
entire framework. I'm not sure if they were from the beginning, but it
seems to be that things are being refctored.
This begs the question of:
If Avalon is a macro view made up of micro components, and Commons is
micro components, when will we hit a stage where we have a redundant
micro-components project, and how should this be dealt with?
My definition of macro vs micro is probably best expressed as giving
someone a lego kit in a box versus giving someone lots of lego bricks. In
the former there is a defined way to build the system, though you can play
with it. In the latter it's entirely up to you.
On Fri, 26 Apr 2002, Berin Loritsch wrote:
> Steven Caswell wrote:
> > I will certainly take a look at Avalon. So why is there a commons pool
> > and commons dbcp if Avalon does the same and more?
> >
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [pool] PROPOSAL: add collecting of statistics to pool implementations
Posted by Berin Loritsch <bl...@apache.org>.
Steven Caswell wrote:
> I will certainly take a look at Avalon. So why is there a commons pool
> and commons dbcp if Avalon does the same and more?
>
Good question. Alot of it is rooted in ideologies. The Pool and
Instrumentation packages can be used quite easily in all kinds of
applications. The DataSourceComponent is an Avalon component--so
you need a compatible container for it. Luckily, Excalibur does
provide one for you--and you can set it up with an XML config file.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [pool] PROPOSAL: add collecting of statistics to pool implementations
Posted by Steven Caswell <st...@caswell.name>.
I will certainly take a look at Avalon. So why is there a commons pool
and commons dbcp if Avalon does the same and more?
Steven Caswell
steven@caswell.name
a.k.a Mungo Knotwise of Michel Delving
"One ring to rule them all, one ring to find them..."
> -----Original Message-----
> From: Berin Loritsch [mailto:bloritsch@apache.org]
> Sent: Wednesday, April 24, 2002 7:46 AM
> To: Jakarta Commons Developers List
> Subject: Re: [pool] PROPOSAL: add collecting of statistics to
> pool implementations
>
>
> Steven Caswell wrote:
> > Proposal: add collecting of statistics to pool implementations
> >
> > Reasoning: I'd like to be able to get stats from a pooling
> > implementation to see how well the various configuration parameters
> > are set. For example, in the GenericObjectPool implementation, I'd
> > like to know how many waits occurred, how many times the pool was
> > extended, etc.
>
>
> <nsip/>
>
>
> Or you can use Avalon Excalibur's Pool and Intrumentation
> packages to have a really good pluggable stat gathering
> system. It also allows you to connect a remote GUI to a
> running system to determine the health :)
>
> --
>
> "They that give up essential liberty to obtain a little
> temporary safety
> deserve neither liberty nor safety."
> - Benjamin Franklin
>
>
> --
> To unsubscribe, e-mail:
> <mailto:commons-dev-> unsubscribe@jakarta.apache.org>
> For
> additional commands,
> e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [pool] PROPOSAL: add collecting of statistics to pool implementations
Posted by Berin Loritsch <bl...@apache.org>.
Steven Caswell wrote:
> Proposal: add collecting of statistics to pool implementations
>
> Reasoning: I'd like to be able to get stats from a pooling
> implementation to see how well the various configuration parameters are
> set. For example, in the GenericObjectPool implementation, I'd like to
> know how many waits occurred, how many times the pool was extended, etc.
<nsip/>
Or you can use Avalon Excalibur's Pool and Intrumentation packages to
have a really good pluggable stat gathering system. It also allows you
to connect a remote GUI to a running system to determine the health :)
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>