DO NOT REPLY [Bug 50306] Detect stuck threads
https://issues.apache.org/bugzilla/show_bug.cgi?id=50306 --- Comment #7 from TomLu 2010-12-29 05:02:04 EST --- Created an attachment (id=26451) --> (https://issues.apache.org/bugzilla/attachment.cgi?id=26451) Patch for Tomcat's ThreadPoolExecutor WebSphere has hung/stuck thread detection logic that has been very useful to us, both in development and production. But since we are moving away from WebSphere, it would be nice to have this kind of feature in Tomcat as well. Some might consider this "stuck thread detection" unnessesary bloat, but we have found it useful on numerous occasions. Applications are never perfect, and often threads will run for too long (resulting in thread leakage and pool depletion): -External connections might hang (like URLConnection) [you can configure read/connect timeout, but not all applications has configured this] -Loops (can be detected by excessive CPU usage) -Loops which does not have excessive CPU usage (for example because it uses external slow IO in each loop iteration, or has Thread.sleep!! (bad coding, but it can happen)) -Deadlocks. -Threads waiting on other hung threads. I have created an experimental patch for Tomcat 7.0.5 that we have been using in development for a short time now. The hung thread monitoring does the following: Monitors active (managed) threads, and issues a warning for each thread that has been active for more than the configured threshold (seconds). The message (log.warn) contains the thread name, stack trace, total time active, and total number of suspected hung threads. (In our environment, we use Cron to scan system.out, and send email if a hung thread is detected.) A timer thread runs at a configurable interval and checks and reports hung threads, and threads previously reported to be hung, but have now finished. It detects hung threads in the HTTP/AJP thread pools. It does not monitor all JVM threads, but since many user threads are spawned from managed "webrequest" threads, the HTTP/AJP threads often waits for user threads to finish, so this patch should give an indication that something is wrong in those cases as well. If anyone is interested, I've attached the patch. This patch is just an example of how such monitoring can be implemented. This is not production ready code. Performance impacts have not been considered! The patch is for the following class: org.apache.tomcat.util.threads.ThreadPoolExecutor It uses 2 system properties for configuration: org.apache.catalina.threadmonitor.interval (in seconds. Default 120) org.apache.catalina.threadmonitor.threshold (in seconds. Default 600) The monitoring is enabled by default, but can be disabled by setting the "interval" to a negative value or 0. As stated, it only monitors managed threads created by Tomcat's HTTP/AJP thread pools. Monitoring all JVM threads is also an option, but may require more code and might lead to many false positives..? The most important thing is to detect problems with stuck HTTP/AJP threads. TODOs: -Should the thread monitor properties be moved to server.xml instead of being System properties? -Add JMX notification when hung thread detected/hung thread finished I have no problem understanding that such a feature might not be seen as useful for everybody. We will continue to patch our own version of Tomcat anyway :) -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 50527] New: misleading error message for unknown message
https://issues.apache.org/bugzilla/show_bug.cgi?id=50527 Summary: misleading error message for unknown message Product: Tomcat 6 Version: 6.0.29 Platform: PC Status: NEW Severity: normal Priority: P2 Component: Catalina AssignedTo: dev@tomcat.apache.org ReportedBy: julian.resc...@gmx.de For unknown HTTP methods, Tomcat says: "...is not defined in RFC 2068 and is not supported by the servlet API" This is misleading. 1) RFC 2068 has been obsoleted by RFC 2616 over 10 years ago. It doesn't matter what it says. 2) As a matter of fact, what RFC 2616 says doesn't matter either. Methods are an extension point, and extension methods work just fine *when implemented*. So the message (in javax/servlet/http/LocalStrings.properties) should be something like: "...is not implemented by this servlet for this URI". -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 50527] misleading error message for unknown HTTP method
https://issues.apache.org/bugzilla/show_bug.cgi?id=50527 Konstantin Kolinko changed: What|Removed |Added Summary|misleading error message|misleading error message |for unknown message |for unknown HTTP method OS/Version||All -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Tomcat 7 & regex
May I suggest you emit a warning to the logs when comma is used in the regexp for a few versions? Hen On Fri, Dec 24, 2010 at 10:34 AM, Mark Thomas wrote: > There are a number of configuration properties defined as "comma > separated regular expressions". As someone pointed out at at ApacheCon > that is a little odd. It stops "," being used in an expression and is > inefficient. > > Having just been bitten by this while setting up the new Jira instance, > I intend change all properties that take regex in Tomcat 7 to use a > single regex. This will simplify the code, simplify configuration and > make the regex processing faster. > > I probably won't get around to actually doing this until the new year. > > Mark > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1053727 - in /tomcat/trunk/webapps/docs: changelog.xml jndi-resources-howto.xml
Author: rjung Date: Wed Dec 29 20:42:04 2010 New Revision: 1053727 URL: http://svn.apache.org/viewvc?rev=1053727&view=rev Log: Improve documentation of database connection factory. Modified: tomcat/trunk/webapps/docs/changelog.xml tomcat/trunk/webapps/docs/jndi-resources-howto.xml Modified: tomcat/trunk/webapps/docs/changelog.xml URL: http://svn.apache.org/viewvc/tomcat/trunk/webapps/docs/changelog.xml?rev=1053727&r1=1053726&r2=1053727&view=diff == --- tomcat/trunk/webapps/docs/changelog.xml (original) +++ tomcat/trunk/webapps/docs/changelog.xml Wed Dec 29 20:42:04 2010 @@ -225,6 +225,9 @@ Correctly validate provided context path so sessions for the ROOT web application can be viewed through the HTML Manager. (markt) + +Improve documentation of database connection factory. (rjung) + Modified: tomcat/trunk/webapps/docs/jndi-resources-howto.xml URL: http://svn.apache.org/viewvc/tomcat/trunk/webapps/docs/jndi-resources-howto.xml?rev=1053727&r1=1053726&r2=1053727&view=diff == --- tomcat/trunk/webapps/docs/jndi-resources-howto.xml (original) +++ tomcat/trunk/webapps/docs/jndi-resources-howto.xml Wed Dec 29 20:42:04 2010 @@ -664,24 +664,108 @@ conn.close(); driverClassName - Fully qualified Java class name of the JDBC driver to be used. -maxActive - The maximum number of active instances -that can be allocated from this pool at the same time. -maxIdle - The maximum number of connections that -can sit idle in this pool at the same time. -maxWait - The maximum number of milliseconds that the -pool will wait (when there are no available connections) for a -connection to be returned before throwing an exception. +username - Database username to be passed to our +JDBC driver. password - Database password to be passed to our JDBC driver. url - Connection URL to be passed to our JDBC driver. (For backwards compatibility, the property driverName is also recognized.) -username - Database username to be passed to our -JDBC driver. +initialSize - The initial number of connections +that will be created in the pool during pool initialization. Default: 0 +maxActive - The maximum number of connections +that can be allocated from this pool at the same time. Default: 8 +minIdle - The minimum number of connections that +will sit idle in this pool at the same time. Default: 0 +maxIdle - The maximum number of connections that +can sit idle in this pool at the same time. Default: 8 +maxWait - The maximum number of milliseconds that the +pool will wait (when there are no available connections) for a +connection to be returned before throwing an exception. Default: -1 (infinite) + +Some additional properties handle connection validation: + validationQuery - SQL query that can be used by the pool to validate connections before they are returned to the application. If specified, this query MUST be an SQL SELECT statement that returns at least one row. +validationQueryTimeout - Timeout in seconds +for the validation query to return. Default: -1 (infinite) +testOnBorrow - true or false: whether a connection +should be validated using the validation query each time it is +borrowed from the pool. Default: true +testOnReturn - true or false: whether a connection +should be validated using the validation query each time it is +returned to the pool. Default: false + +The optional evictor thread is responsible for shrinking the pool +by removing any conections which are idle for a long time. The evictor +does not respect minIdle. Note that you do not need to +activate the evictor thread if you only want the pool to shrink according +to the configured maxIdle property. +The evictor is disabled by default and can be configured using +the following properties: + +timeBetweenEvictionRunsMillis - The number of +milliseconds between consecutive runs of the evictor. +Default: 30*60*1000 (30 minutes) +numTestsPerEvictionRun - The number of connections +that will be checked for idleness by the evitor during each +run of the evictor. Default: 3 +minEvictableIdleTimeMillis - The idle time in +milliseconds after which a connection can be removed from the pool +by the evictor. Default: -1 (disabled) +testWhileIdle - true or false: whether a connection +should be validated by the evictor thread using the validation query +while sitting idle in the pool. Default: false + +Another optional feature is the removal of abandoned conne
DO NOT REPLY [Bug 50306] Detect stuck threads
https://issues.apache.org/bugzilla/show_bug.cgi?id=50306 --- Comment #8 from Pid 2010-12-29 16:47:42 EST --- If I understand the patch correctly, I disagree with the idea of an arbitrary (even if configurable) time threshold per thread. A long running thread is not necessarily a broken one; there are existing methods in JMX for identifying deadlocked threads. The same could be achieved with a Valve in the request processing pipeline, without modifying the Executor. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
