-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Felix,
On 1/3/13 3:49 PM, Felix Schumacher wrote: > Am 03.01.2013 15:31, schrieb kharp...@oreillyauto.com: >> Hello All, >> >> Yesterday we had a Tomcat6 server reach maxThreads and stay that >> way until we restarted it. After researching a thread dump and >> some log files, we found one of the applications is creating >> NullPointerExceptions and subsequently leaving a TP-ProcessorX in >> WAITING state indefinitely for a DB closePreparedStatement >> return. As more requests come in for this application threads >> are being established and put into BLOCKED state, waiting on >> TP-ProcessorX. Eventually, the server hits maxThreads and stops >> serving requests almost entirely. >> >> Obviously the application causing this needs to (and is being) >> fixed. But I'm curious if there is a higher level of protection >> that could be implemented to help protect the other applications >> (contexts) on this server? For example, is there a way to >> specify that a context can only use X number of request threads? >> Or perhaps X number of threads from an executor? Et cetera. > > On tomcat 6 - at least the most recent one - there is a Valve which > can limit the concurrent access to a context. Sadly it seems not to > be mentioned in the docs. So you would have to look at the code to > see the possible params (concurrency [=10], fairness [=false], > blocking [=true], interruptible [=false]) and the name > (org.apache.catalina.valves.SemaphoreValve) to be able to add the > (hopefully) right entry to your context: The last modification to that class was 2010-04-29, so everyone should have it by now. Then again, lots of people are still running 5.5.8 or whatever, so what do I know... > <Valve class="org.apache.catalina.valves.SemaphoreValve" > concurrency="25" blocking="false" /> > > I haven't tested it, but it should limit the concurrent threads > used by that context to 25 at most and give an error to any request > while those threads stay busy. Note that blocking=false will likely result in lots of requests being essentially rejected: the client will get a 200 OK response with no content at all. On the other hand, if you allow blocking, then the result will be the same as if the valve hadn't been installed: all requests will wait until all of them are stuck in the "closePreparedStatement" trap. The point is that installing the SemaphoreValve will merely change the exact circumstances under which this application comes grinding to a halt. If you are trying to protect *other* webapps from this problem, then use of the SemaphoreValve might be of some use. Otherwise, the effect will be of simply lowering the maxActive setting on your <Executor> (with the notable exception that clients will immediately get a useless response instead of waiting forever for no response). (If you subclass the Valve and override the permitDenied method, you can return any response you wish, which might be a good idea.) - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEAREIAAYFAlDnYj4ACgkQ9CaO5/Lv0PAtGACeMfXEI+4vAKIWh/oHRIRs7gJ9 p54AoKxfbGHQhd7wQJiuYbwwMeczb6xN =+uJw -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
