commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <cost...@covalent.net>
Subject RE: [pool] PROPOSAL: add collecting of statistics to pool impleme ntations
Date Mon, 29 Apr 2002 16:25:49 GMT
On Mon, 29 Apr 2002, Steven Caswell wrote:

> My problem is one of keeping the design clean. My view of Excalibur is
> that it sits in a domain higher than commons. I see Excalibur as being
> at an architcture level, and I see commons as being more at a foundation
> level. I hesitate to have a commons package "reach" up into a higher
> domain.

Everyone is free to have its views, of course.

Most people around here view commons as a foundation level and a
collection of packages we use in our other projects.

And the 'architecture' level is usually dicated by the project
that uses the component - so most component do try to stay 
'architecture-neutral' and/or support multiple architectures 
( usually the ones of the projects embedding them ).

If Excalibur has code that could be used in multiple projects - 
it is wellcomed in commons, or it can release it independently.

Costin


> 
> Having said that, I suspect there are packages in Excalibur that really
> ought to be at a foundation level, and there are packages in commons
> that ought to be at an architecture level. Perhaps pool should
> eventually be migrated to Excalibur. Perhaps better organization of
> Jakarta projects along domain lines would be appropriate. And perhaps I
> need to decide if a pooling package is really foundational (as I would
> label one in commons) or architectural (as I would label one in
> Excalibur) and have my application architecture based on the most
> appropriate domain. Perhaps the current reorg of Excalibur will make it
> easier for me to do this.
> 
> However, for the present, I would like to make the pooler I'm better by
> adding statistics gathering. And for the present, the most expedient way
> I see to do that is the implementation I proposed.
> 
> 
> 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: Monday, April 29, 2002 9:51 AM
> > To: Jakarta Commons Developers List
> > Subject: Re: [pool] PROPOSAL: add collecting of statistics to 
> > pool impleme ntations
> > 
> > 
> > Waldhoff, Rodney wrote:
> > >>I'd rather hear from the commons pool community as to whether my 
> > >>proposal
> > > 
> > > is
> > > 
> > >>+1, and if not, what I can do to make it better from the community
> > >>standpoint.
> > > 
> > > 
> > > Can't speak for the "community", but I'm +1 on the idea.  I 
> > imagine a 
> > > "wrapper" style implementation that allow one to collect stats on a 
> > > arbitrary pool, right?
> > > 
> > 
> > Why not just *use* Excalibur Instrumentation?  It does not 
> > require using all of Avalon, it is light weight, and first 
> > rate.  Leif did a great job of balancing performance and 
> > memory consumption.
> > 
> > You don't have to use Excalibur pool impls, but the 
> > instrumentation code would help in debugging any arbitrary 
> > stat you want with graphs that you can view in real time.  
> > There's nothing like being able to attach the GUI client to 
> > an already *running* process, and then shutting down the 
> > client without shutting down the server code.
> > 
> > Talk about easing remote administration....
> > 
> > This is an area where I think that duplication might be a 
> > wasteful activity.  Sure, keep your pool implementation, but 
> > provide a version that uses Excalibur Instrumentation if the 
> > libs are included at compile time.
> > 
> > There is *alot* that goes on behind the scenes, and to get to 
> > where Instrumentation is, is going to take a while.  We 
> > started playing with the idea either early this year or late 
> > last year--but didn't have anything working until about a 
> > month or two ago.
> > 
> > That is unless you *really* want to reinvent the wheel--which 
> > I cannot stop.  However, as the JMeter team can tell 
> > you--memory leaks are a b*tch to track down in GUI apps.
> > 
> > -- 
> > 
> > "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: <mailto:commons-dev-help@jakarta.apache.org>
> > 
> > 
> 
> 
> 
> --
> To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>
> 
> 


--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message