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:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
