-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Keen Jan,
Kees Jan Koster wrote: > 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 ;) >> What limits are relevant? For instance, Java doesn't allow you to have >> any method with more than 64k of code. I suppose that's of little >> consequence to a running JVM, since the code would never be loaded. > > Yes, I ran into that limit for a generated servlet once. This is not the > kind of limit that I am looking for, as it is caught compile-time, not > run-time. Yup: one big, nasty JSP will get you some day. >> 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. >> 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. > 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). - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkkkJikACgkQ9CaO5/Lv0PBuXQCeKp58nHImA6fWFpQmwL59+h9l uqkAoMKrYz4eRVN8rt57KzPcwVlzQFIM =P2f6 -----END PGP SIGNATURE----- --------------------------------------------------------------------- To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
