DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=32316>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=32316 Summary: Limiting new application sessions if load is to high Product: Tomcat 5 Version: 5.0.30 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: Native:JK AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Limiting new application sessions if load is to high. This enhancement should prevent complex systems from being flooded if some backend system gets stuck or answers too slowly for some time. Users already logged into an application might still be able to work successfully, but new users get a very fast static response to prevent the incoming channels (TCP-Connections, Threads, ...) from being flooded. Implementation suggestion Use a mod_jk-configurable start URL for the application (regexp based). If a request X matches this URL, then mod_jk checks the scoreboard how many apache requests are being processed simultaneously at that moment. There is a configurable limit, and if that limit is reached, the request X will not be sent to tomcat, but instead be answered by some configurable "local" static response (containing the info, that the load is to high and the user should try again later). Alternatively one can configure X to be answered by some external redirect. Although the mechanism is for prevention of the application, counting tomcat requests or counting all requests (inclusive static ones) does not really make a difference according to our experiance. Static content usually serves in very well under a second (depending mostly on internet speed). The idea here is to detect a problem with the application getting slow, e.g. because of backend systems not responding fast enough. In this situation we want to limit creation of new sessions. Example: During normal operation there are 5 static requests in work and 10 dynamic ones (that take much longer to complete). When there is a problem with backend systems we might have 15 static ones, but more than 100 dynamic ones. So either counting or ommiting the static ones seems to make no big difference. You might want to take a look at the attached patch "patch_overload.txt" for jk/native/apache1.3/mod_jk.c version 1.52. I don't have a patch for Apache 2, but Mladen Turk has something similar for Apache 2. This patch here places every change inside "#ifdef OVERLOAD". Also there are some DEBUG-Log-Statements put inside "#ifdef DEBUG" which I assume can now be done more consistently with Mladen Turks TRACE features. Of course the "best" observable value would be the number of requests belonging to the same webapp. So some possible enhancement would be to count only requests with a fix URL prefix (that's not yet contained in the patch). -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
