Dear Chris,
Ah, sorry for the confusion. I should have asked for limits that are
hard at run-time. Thread pool sizes may be editable, but they are
fixed
once Tomcat runs.
Gotcha. Hard runtime limits makes a whole lot more sense. Sorry for
not
jumping to that obvious conclusion. I wasn't trying to be a jerk ;)
Don't worry. Better to ask for clarification than to assume. I wish
more people would follow your example.
If you are going to count memory (heap?) and file descriptors, I
suppose
you could also count CPU time, since that is a limitable resource on
*NIX systems.
Hmm. It's really only useful if I can monitor both the maximum
available
time and the used time. I have no idea how I would measure that,
even at
unix level. It gets even more messy in virtual servers.
I don't see why virtual servers would be trickier: the kernel should
be
counting beans properly. In terms of getting that information, you
need
to call getrlimit to see what the limit is. I'm not sure where to get
the current resource usage, though.
Hmmyeah. We're way off into OS-land here.
Virtual servers get esepcially tricky when a few are running on a host
and you're in one of them. You may still be able to measure your own
cpu usage, but you have no idea at all how much was available. So you
can never tell if you're using what is available or not. I run Java-
monitor's components on the bare iron for that very reason. So that I
can see what uses the cpu and optimise the right places.
If you really are talking about soft limits, then you probably
also want
to see the number of requests accepted but not yet being handled
(controlled by the <Connector>'s "acceptCount" attribute), the
number of
request processors (is this "thread pools" above?), the number of
connections total/available/used in JDBC connection pools.
Ah, that is interesting too: queue fill levels that should under
normal
circumstances be more or less empty. Much like the
ObjectPendingFinalizationCount. Thanks for that.
How would I use it, though? In my Tomcat acceptCount has a value of
100.
That's probaly an upper limit. What is the 'un-use' property that
goes
with this upper limit?
Do you mean something like a minimum accept count? By definition, the
minimum accept count is 0, since you're talking about the number of
connections that the socket will accept. It can certainly always be
zero. But this is an OS thing, and is set when you bind to the
socket. I
don't think there's a way to change this through Java after the socket
has been bound.
Grr. Off into OS-land again. Oh well. :-)
What MBean can I talk to about JDBC connection pooling?
You should get yourself a copy of LabmdaProbe and basically steal all
that code. Better yet, just use LambdaProbe and save yourself a lot of
headache. I'm sure they'd appreciate any code you'd like to donate to
the project to sniff other limits (like file descriptors).
Yes, LambdaProbe sure looks nice. My probe code is available from
Google code (http://code.google.com/p/java-monitor-probes/) but really
all I do so query JMX mbeans.
Hmm. Maybe I should talk to the devs of the new default connection
pool to incorporate a pool MBean too. That's useful for all of us,
regardless of monitoring tool in use.
For Java-monitor I have to keep in mind that I cannot do anything
invasive. I want the probe to be so lightweigth that installation is a
mere 5 minutes work and has no measurable impact on the JVM's run-time
performance.
--
Kees Jan
http://java-monitor.com/forum/
[EMAIL PROTECTED]
06-51838192
Human beings make life so interesting. Do you know that in a universe
so full of wonders,
they have managed to invent boredom. Quite astonishing... -- Terry
Partchett
--
Kees Jan
http://java-monitor.com/forum/
[EMAIL PROTECTED]
06-51838192
The secret of success lies in the stability of the goal. -- Benjamin
Disraeli
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
