RE: Limit user sessions in tomcat
This is an application level problem. You need to implement your own synchronization/locking system to prevent this from happening. If you're running reports that are taking a while, you might want to consider creating a system that will email the results to the clients rather than making them wait. George Sexton MH Software, Inc. http://www.mhsoftware.com/ Voice: 303 438 9585 -Original Message- From: Chetan Chheda [mailto:chetan_chh...@yahoo.com] Sent: Tuesday, December 15, 2009 9:04 AM To: users@tomcat.apache.org Subject: Limit user sessions in tomcat Hello, We frequently have situations where a user has brought down a tomcat entirely by himself by running the same transaction multiple times because the response was not quick enough. Is there a way through configuation of tomcat and mod_jk to control the number of concurrent transactions/sessions a user can maintain? Since this is something that can happen to anyone out there, I am curious as to how you are handling this scenario.. Thanks, Chetan - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Limit user sessions in tomcat
From: Chetan Chheda [mailto:chetan_chh...@yahoo.com] Subject: Limit user sessions in tomcat Is there a way through configuation of tomcat and mod_jk to control the number of concurrent transactions/sessions a user can maintain? Don't know about what you might be able to configure in httpd, but in Tomcat this is frequently done with a filter in conjunction with an HttpSessionListener to insure a user session is being used by an excessive number of concurrent requests. This keeps the throttling independent of the logic in the webapp. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Limit user sessions in tomcat
Caldarale, Charles R wrote: From: Chetan Chheda [mailto:chetan_chh...@yahoo.com] Subject: Limit user sessions in tomcat Is there a way through configuation of tomcat and mod_jk to control the number of concurrent transactions/sessions a user can maintain? Don't know about what you might be able to configure in httpd, but in Tomcat this is frequently done with a filter in conjunction with an HttpSessionListener to insure a user session is being used by an excessive number of concurrent requests. This keeps the throttling independent of the logic in the webapp. There exist a couple of add-on filter modules at the Apache level to handle that kind of thing. It might be better to do it at the earliest possible level, before you even hit mod_jk or Tomcat. On another level, I don't quite understand yet how this squares with the fact that most browsers will not establish more than 2 connections with the same webserver at the same time. It seems a bit difficult to imagine that one single user can crash a Tomcat just by repeatedly hitting the same link. Maybe the OP should just find that user and tell him to stop doing that. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Limit user sessions in tomcat
2009/12/15 André Warnier a...@ice-sa.com On another level, I don't quite understand yet how this squares with the fact that most browsers will not establish more than 2 connections with the same webserver at the same time. It seems a bit difficult to imagine that one single user can crash a Tomcat just by repeatedly hitting the same link. As far as the browser's concerned, clicking a link while a request is pending cancels the previous request (and generally closes the socket) and opens a new one. So it only has one connection open at any one time. As far as Tomcat's concerned - as shown by the recent emails on the topic - there's no way of detecting that closed socket and stopping its thread from trying to service it. So old requests build up, unwanted but impossible to discard until they complete or try to write something to the (closed) socket. - Peter
RE: Limit user sessions in tomcat
From: André Warnier [mailto:a...@ice-sa.com] Subject: Re: Limit user sessions in tomcat On another level, I don't quite understand yet how this squares with the fact that most browsers will not establish more than 2 connections with the same webserver at the same time. Because when you click on another link (or re-click the same one), the browser closes its end of the connection to the server, and opens another one. Closing the client end is pretty much invisible to the server until it attempts to send a response, which won't happen until the webapp finishes processing the now useless request. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Limit user sessions in tomcat
Andre, We have a vast user population thats geographically dispersed, so implementing something thru the system would be the favourable approach.. Can you point me to links on the web that explain the add on modules and their implementation? All, Is there a 3rd party tool available to manage tomcat sessions and kill them once they go rogue? We dont have an inhouse development staff, so the best approach would be buying something off the shelf if it exists.. Thanks, Chetan From: Peter Crowther peter.crowt...@melandra.com To: Tomcat Users List users@tomcat.apache.org Sent: Tue, December 15, 2009 12:07:15 PM Subject: Re: Limit user sessions in tomcat 2009/12/15 André Warnier a...@ice-sa.com On another level, I don't quite understand yet how this squares with the fact that most browsers will not establish more than 2 connections with the same webserver at the same time. It seems a bit difficult to imagine that one single user can crash a Tomcat just by repeatedly hitting the same link. As far as the browser's concerned, clicking a link while a request is pending cancels the previous request (and generally closes the socket) and opens a new one. So it only has one connection open at any one time. As far as Tomcat's concerned - as shown by the recent emails on the topic - there's no way of detecting that closed socket and stopping its thread from trying to service it. So old requests build up, unwanted but impossible to discard until they complete or try to write something to the (closed) socket. - Peter
Re: Limit user sessions in tomcat
2009/12/15 Chetan Chheda chetan_chh...@yahoo.com Is there a 3rd party tool available to manage tomcat sessions and kill them once they go rogue? Can I just check two pieces of terminology? In Tomcat (and many other web servers), a session is the notion that a user will make multiple requests to the server from the same browser over time. It's also used to refer to any data that the application keeps between these requests from the same user. I'm not aware of a way that a session could go rogue except by getting more and more data stored in it - in which case, it's time to file a bug report with your external development house and tell them to fix the leaky code! A single request to the server is one HTTP request from the browser* to the server, and the response from server to browser. This can cause problems if it takes a long time to service. Each request uses one thread while it is being serviced, then that thread is returned to the pool once the request completes. I'm not aware of any tool that will allow you to kill threads in the middle of a request if they go rogue. Are you having problems with rogue (large) sessions, or with rogue (long-running) requests? - Peter * Yes, to the pedants out there, I know this should more generally be called a user-agent or even a client, as so many HTTP requests now come from web services.
Re: Limit user sessions in tomcat
Thanks Peter for the clarification. My background is that of a UNIX administrator not a web administrator and its showing from my posts.. My problem is long running requests. If the requests take longer than their fancy, the users just close the browser window, open a new one and resubmit the same request. I also noticed a lot of the following in my mod_jk logs which to me means the user killed the browser? ... [Tue Dec 15 02:56:30.491 2009] [3460:93] [info] jk_ajp_common.c (1688): Writing to client aborted or client network problems [Tue Dec 15 02:56:30.492 2009] [3460:93] [info] jk_ajp_common.c (2315): (31) sending request to tomcat failed (unrecoverable), becau se of client write error (attempt=1) [Tue Dec 15 02:56:30.778 2009] [3460:93] [info] jk_lb_worker.c (1339): service failed, worker 31 is in error state [Tue Dec 15 02:56:30.778 2009] [3460:93] [info] jk_lb_worker.c (1360): unrecoverable error 200, request failed. Client failed in the middle of request, we can't recover to another instance. [Tue Dec 15 02:56:30.778 2009] [3460:93] [info] mod_jk.c (2421): Aborting connection for worker=loadbalancer From: Peter Crowther peter.crowt...@melandra.com To: Tomcat Users List users@tomcat.apache.org Sent: Tue, December 15, 2009 12:42:01 PM Subject: Re: Limit user sessions in tomcat 2009/12/15 Chetan Chheda chetan_chh...@yahoo.com Is there a 3rd party tool available to manage tomcat sessions and kill them once they go rogue? Can I just check two pieces of terminology? In Tomcat (and many other web servers), a session is the notion that a user will make multiple requests to the server from the same browser over time. It's also used to refer to any data that the application keeps between these requests from the same user. I'm not aware of a way that a session could go rogue except by getting more and more data stored in it - in which case, it's time to file a bug report with your external development house and tell them to fix the leaky code! A single request to the server is one HTTP request from the browser* to the server, and the response from server to browser. This can cause problems if it takes a long time to service. Each request uses one thread while it is being serviced, then that thread is returned to the pool once the request completes. I'm not aware of any tool that will allow you to kill threads in the middle of a request if they go rogue. Are you having problems with rogue (large) sessions, or with rogue (long-running) requests? - Peter * Yes, to the pedants out there, I know this should more generally be called a user-agent or even a client, as so many HTTP requests now come from web services.
Re: Limit user sessions in tomcat
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 André, On 12/15/2009 12:01 PM, André Warnier wrote: On another level, I don't quite understand yet how this squares with the fact that most browsers will not establish more than 2 connections with the same webserver at the same time. Things have changed: http://www.webperformanceinc.com/library/reports/LoadTesting-IE8-Firefox/ It seems a bit difficult to imagine that one single user can crash a Tomcat just by repeatedly hitting the same link. If the webapp has been written in a way to allow it, this is definitely possible: write a long-running backend process and have the user click GO GO GO GO GO GO GO GO GO and suddenly you have lots of long-running backend processes running. Since the webapp doesn't try to write to the response during that time, Tomcat happily executes each request to completion without knowing that the client has hung up the phone. Maybe the OP should just find that user and tell him to stop doing that. :) - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAksn09UACgkQ9CaO5/Lv0PAOqgCfaT7o1QW0SNw3ORtD04nrDLnH q78AoIIKIshmnyNbAWBGS3U/wUDkbu7h =SrvE -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Limit user sessions in tomcat
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chetan, On 12/15/2009 11:03 AM, Chetan Chheda wrote: We frequently have situations where a user has brought down a tomcat entirely by himself by running the same transaction multiple times because the response was not quick enough. Does this usually end up being the same transaction (just one problematic service) or do you have many that could exhibit this problem? Is there a way through configuation of tomcat and mod_jk to control the number of concurrent transactions/sessions a user can maintain? No, but you can write some code to do it. Since this is something that can happen to anyone out there, I am curious as to how you are handling this scenario. We do not have such a problem on any of our webapps (that I know of), but here's what I would do: write a filter. This filter will: a. Check the user's session for a marker object. Let's call it DUPLICATE_REQUEST_MARKER. b. If the DUPLICATE_REQUEST_MARKER is present, we either: i. do a RUPLICATE_REQUEST_MARKER.wait() or ii. return an error message to the user (your choice, depending on your requirements) c. If the DUPLICATE_REQUEST_MARKER is not present, then i. create a DUPLICATE_REQUEST_MARKER and put it in the session ii. allow the request to continue iii. call DUPLICATE_REQUEST_MARKER.notify iv. remove DUPLICATE_REQUEST_MARKER from the session (Not sure if 'iv' and 'iii' above should be reversed... I haven't really thought about it much). Now, you can simply declare this filter in web.xml and map it to whatever problematic URLs you might have. This will allow a single user (as defined by their session) to perform only one long-running request at a time. If you want, you can go crazy with complex threading acrobatics like trying to interrupt the already-running thread so it stops processing the (presumed) aborted request, etc. but this should be enough to get you going, and prevent a single user from bringing down your application. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAksn1b0ACgkQ9CaO5/Lv0PCgyQCdFDv8ErN68mlXTRjBCzLdt18J JvQAoLIUJWrinTiHs/d33F6mi1B10qv7 =mlFy -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Limit user sessions in tomcat
Chetan Chheda wrote: Andre, We have a vast user population thats geographically dispersed, so implementing something thru the system would be the favourable approach.. Can you point me to links on the web that explain the add on modules and their implementation? All, Is there a 3rd party tool available to manage tomcat sessions and kill them once they go rogue? We dont have an inhouse development staff, so the best approach would be buying something off the shelf if it exists.. For something at the apache httpd front-end level, maybe start with a Google search for apache mod_cband. A direct link : http://codee.pl/cband.html I am suggesting this because you were mentioning mod_jk, implying that you have an Apache httpd front-end. I believe that if you want to limit this kind of thing, it is better to do it as early as possible when a request comes in, rather than waiting until an Apache/Tomcat connection is already established, and a Tomcat thread if already dedicated to processing this request (if only to reject it later). At the Apache level, instead of using something like JkMount /myApp ajp13 JkMount /myApp/* ajp13 to select which requests will be forwarded by Apache, via mod_jk, to Tomcat, you can use the alternative setup explained at the very end of this page : http://tomcat.apache.org/connectors-doc/reference/apache.html I find that this provides a clearer way to combine Apache configuration directives with the mod_jk proxying instructions. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Limit user sessions in tomcat
Chetan Chheda wrote: Thanks Peter for the clarification. My background is that of a UNIX administrator not a web administrator and its showing from my posts.. My problem is long running requests. If the requests take longer than their fancy, the users just close the browser window, open a new one and resubmit the same request. I also noticed a lot of the following in my mod_jk logs which to me means the user killed the browser? ... [Tue Dec 15 02:56:30.491 2009] [3460:93] [info] jk_ajp_common.c (1688): Writing to client aborted or client network problems [Tue Dec 15 02:56:30.492 2009] [3460:93] [info] jk_ajp_common.c (2315): (31) sending request to tomcat failed (unrecoverable), becau se of client write error (attempt=1) [Tue Dec 15 02:56:30.778 2009] [3460:93] [info] jk_lb_worker.c (1339): service failed, worker 31 is in error state [Tue Dec 15 02:56:30.778 2009] [3460:93] [info] jk_lb_worker.c (1360): unrecoverable error 200, request failed. Client failed in the middle of request, we can't recover to another instance. [Tue Dec 15 02:56:30.778 2009] [3460:93] [info] mod_jk.c (2421): Aborting connection for worker=loadbalancer This is typically the case you indicate : - a user clicks on a link, sending a request to Apache - Apache passes the request to mod_jk and waits for mod_jk to provide a response - mod_jk forwards the request to Tomcat - Tomcat receives the request and passes it to a thread for execution - the thread takes xxx time to process the request and produce the response - the thread sends the response back to mod_jk, and is now done - mod_jk wants to send the response back to Apache (and the client), but on writing to the client socket, gets an error, namely that the other end is no longer there (the client browser has closed the connection, because the user clicked somewhere else, maybe several minutes ago) - mod_jk logs the error above - but by that time, it is too late to do anything useful about it in Tomcat, because the webapp thread has already done all its processing for the request (uselessly). At the Tomcat webapp level, you can either do something like Christopher is suggesting (which avoids *accepting* additional identical requests from the same client, until this request is processed), or you can try to modify the application so that it at least starts returning something to the client very early in the request processing cycle. If it does that, it will get the error which mod_jk is seeing, bubbled up to its own response socket, much earlier. That may at least avoid unnecessary processing. Or again, you can try and catch these events much earlier, before they even get to Tomcat and start using up Tomcat resources. Being myself an Apache/mod_perl guy more than a Tomcat/Java guy, I would do this by means of a PerlAccessHandler at the Apache front-end level, implementing much the same logic as Chris mentions in his post about a servlet filter. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
