Re: [OT - question] Limit user sessions in tomcat
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chuck, On 12/15/2009 5:01 PM, Caldarale, Charles R wrote: From: André Warnier [mailto:a...@ice-sa.com] Subject: Re: [OT - question] Limit user sessions in tomcat It would seem that there ought to be some low-level response-direction socket flag that should be available, to tell whether the receiving end has gone, without actually having to send anything from a higher-level code module. But getting to that low-level socket data does not seem to be so easy in Java, is it ? It's not hard in Java (Socket.getRemoteSocketAddress() or Socket.isConnected() should work), but there's nothing in the servlet spec that allows a servlet thread to obtain for that information. Ideally, the container (Tomcat) would asynchronously monitor the socket status and set some flag in the Request object for the webapp code to examine at its leisure. Might also be able to implement this with a new form of listener. I thought it was sufficient to call response.flush. Maybe you have to actually write 0 bytes and then flush (like out.write(buffer, 0, 0); out.flush()). But, I haven't actually tried it so I can't confirm. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAksqlKwACgkQ9CaO5/Lv0PBrHQCgvR5Sce7ss+a6VFKM67qLA6+D S4sAn22RBcixFep3P06cZt8WCLPY9f1v =huNc -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
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
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: [OT - question] Limit user sessions in tomcat
Are there any standard techniques that a /developer/ of such a long running prccess could apply to wrap the process in a cocoon which periodically updates a browser with (real) progress data, and at the same time, such updates are verifications that the socket is still live and the user hasn't gone away; if the user has gone away, that would be detected and the wrapper would kill the process?? Thanks --Ken On Dec 15, 2009, at 1:22 PM, Christopher Schultz wrote: -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 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [OT - question] Limit user sessions in tomcat
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ken,
On 12/15/2009 1:52 PM, Ken Bowen wrote:
Are there any standard techniques that a /developer/ of such a long
running proccess could apply to wrap the process in a cocoon which
periodically updates a browser with (real) progress data, and at the
same time, such updates are verifications that the socket is still
live and the user hasn't gone away; if the user has gone away, that
would be detected and the wrapper would kill the process??
Uh, probably :)
You'd probably want to do a few things:
1. Use a thread pool. This allows you to use your own threads to either
do the real work, or to manage the connections back to the client. I
recommend the former, and allowing Tomcat's threads to mostly sit idle
while the thread pool does your long-running business tasks.
2. All your tasks need to be gracefully interruptable. If you are doing
long-running database queries, then I'm not sure what you could do,
since you're just waiting on the server. If you want to limit query
time, there are methods in JDBC that allow you to at least request a
time limit on a query (see Statement.setQueryTimeout), though that won't
really help you out much because the query will simply be aborted after
a certain amount of time.
One way to make these tasks gracefully interruptable is to have them
periodically check a stop flag that is accessible by the task itself,
but also settable by, say, another thread. If the stop flag is ever
true, clean everything up and stop the task, preferably indicating to
the caller that the task was stopped instead of completing.
3. Have your webapp's code (running in the Tomcat-managed thread) poll
for activity. Something like this:
doGet() {
Future future = new Task(); // be creative: see java.util.concurrent
try {
while(!future.isDone()) {
try {
Object result = future.get(1, TimeUnit.SECONDS);
} catch (TimeoutException te) {
response.flush(); // does this work?
// now, just keep waiting...
}
}
// send good response to client
} catch (InterruptedException ie) {
future.cancel();
response.sendError();
} catch (IOException ioe) {
// client disconnected
future.cancel();
response.sendError();
} finally {
future.cancel(); // just in case
}
}
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAksn354ACgkQ9CaO5/Lv0PAQCgCfQGNbT9xF4FZ2PewPnFE52m8S
BhoAni5ya2Yye8sO6YWjqjvB4Gxu79IU
=WF/0
-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
Re: [OT - question] Limit user sessions in tomcat
Chris,
Thanks. We do #1 routinely, usually setting the thread(s) up as workers
managing a queue. #2 can be problematic as you note: long-running db
queries or long graphics generation are hard to fit into this model
simply
because one is using someone else's monolithic code that makes no such
provisions. #3 is what I was wondering about. So far our long tasks
haven't
been terribly long, but some are reaching that (user-frustration)
boundary.
Cheers,
Ken
On Dec 15, 2009, at 2:12 PM, Christopher Schultz wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ken,
On 12/15/2009 1:52 PM, Ken Bowen wrote:
Are there any standard techniques that a /developer/ of such a long
running proccess could apply to wrap the process in a cocoon which
periodically updates a browser with (real) progress data, and at the
same time, such updates are verifications that the socket is still
live and the user hasn't gone away; if the user has gone away, that
would be detected and the wrapper would kill the process??
Uh, probably :)
You'd probably want to do a few things:
1. Use a thread pool. This allows you to use your own threads to
either
do the real work, or to manage the connections back to the client. I
recommend the former, and allowing Tomcat's threads to mostly sit idle
while the thread pool does your long-running business tasks.
2. All your tasks need to be gracefully interruptable. If you are
doing
long-running database queries, then I'm not sure what you could do,
since you're just waiting on the server. If you want to limit query
time, there are methods in JDBC that allow you to at least request a
time limit on a query (see Statement.setQueryTimeout), though that
won't
really help you out much because the query will simply be aborted
after
a certain amount of time.
One way to make these tasks gracefully interruptable is to have them
periodically check a stop flag that is accessible by the task
itself,
but also settable by, say, another thread. If the stop flag is ever
true, clean everything up and stop the task, preferably indicating to
the caller that the task was stopped instead of completing.
3. Have your webapp's code (running in the Tomcat-managed thread) poll
for activity. Something like this:
doGet() {
Future future = new Task(); // be creative: see java.util.concurrent
try {
while(!future.isDone()) {
try {
Object result = future.get(1, TimeUnit.SECONDS);
} catch (TimeoutException te) {
response.flush(); // does this work?
// now, just keep waiting...
}
}
// send good response to client
} catch (InterruptedException ie) {
future.cancel();
response.sendError();
} catch (IOException ioe) {
// client disconnected
future.cancel();
response.sendError();
} finally {
future.cancel(); // just in case
}
}
- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAksn354ACgkQ9CaO5/Lv0PAQCgCfQGNbT9xF4FZ2PewPnFE52m8S
BhoAni5ya2Yye8sO6YWjqjvB4Gxu79IU
=WF/0
-END PGP SIGNATURE-
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [OT - question] Limit user sessions in tomcat
Ken Bowen wrote: Chris, Thanks. We do #1 routinely, usually setting the thread(s) up as workers managing a queue. #2 can be problematic as you note: long-running db queries or long graphics generation are hard to fit into this model simply because one is using someone else's monolithic code that makes no such provisions. #3 is what I was wondering about. So far our long tasks haven't been terribly long, but some are reaching that (user-frustration) boundary. All in all, it seems quite a messy problem. To really detect that the client has gone while you are still doing something for him, would require : 1) the ability to send from time to time some output to the client, which a) would generate an error if the client has really gone and the socket is closed in that direction b) but would not disturb the client in any way if per chance it is still there and waiting for an answer. 2) the ability to do this asynchronously with the real request processing which is taking place in the meantime 3) a mechanism for, in case the client has gone in the meantime, telling the process that is processing the request, that it can drop it and discard whatever it wanted to output. Or alternatively, a method for killing the request-processing process properly from outside. 4) a mechanism for cleaning this all up properly when the real response output has been initiated. 5) the ability to set this up selectively only for requests likely to take a certain time to process, so as not make the whole thing very inefficient. It would seem that there ought to be some low-level response-direction socket flag that should be available, to tell whether the receiving end has gone, without actually having to send anything from a higher-level code module. But getting to that low-level socket data does not seem to be so easy in Java, is it ? I remember trying once to get back there starting from the HttpServletResponse object, and not getting anywhere fast. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: [OT - question] Limit user sessions in tomcat
From: André Warnier [mailto:a...@ice-sa.com] Subject: Re: [OT - question] Limit user sessions in tomcat It would seem that there ought to be some low-level response-direction socket flag that should be available, to tell whether the receiving end has gone, without actually having to send anything from a higher-level code module. But getting to that low-level socket data does not seem to be so easy in Java, is it ? It's not hard in Java (Socket.getRemoteSocketAddress() or Socket.isConnected() should work), but there's nothing in the servlet spec that allows a servlet thread to obtain for that information. Ideally, the container (Tomcat) would asynchronously monitor the socket status and set some flag in the Request object for the webapp code to examine at its leisure. Might also be able to implement this with a new form of listener. I haven't looked at the Servlet 3 spec to see if anything is in there for this rather common problem. - 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: [OT - question] Limit user sessions in tomcat
On 15/12/2009 22:01, Caldarale, Charles R wrote: From: André Warnier [mailto:a...@ice-sa.com] Subject: Re: [OT - question] Limit user sessions in tomcat It would seem that there ought to be some low-level response-direction socket flag that should be available, to tell whether the receiving end has gone, without actually having to send anything from a higher-level code module. But getting to that low-level socket data does not seem to be so easy in Java, is it ? It's not hard in Java (Socket.getRemoteSocketAddress() or Socket.isConnected() should work), but there's nothing in the servlet spec that allows a servlet thread to obtain for that information. Ideally, the container (Tomcat) would asynchronously monitor the socket status and set some flag in the Request object for the webapp code to examine at its leisure. Might also be able to implement this with a new form of listener. I haven't looked at the Servlet 3 spec to see if anything is in there for this rather common problem. Comet? p 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 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [OT - question] Limit user sessions in tomcat
On Tue, Dec 15, 2009 at 11:01 PM, Caldarale, Charles R chuck.caldar...@unisys.com wrote: From: André Warnier [mailto:a...@ice-sa.com] Subject: Re: [OT - question] Limit user sessions in tomcat It would seem that there ought to be some low-level response-direction socket flag that should be available, to tell whether the receiving end has gone, without actually having to send anything from a higher-level code module. But getting to that low-level socket data does not seem to be so easy in Java, is it ? It's not hard in Java (Socket.getRemoteSocketAddress() or Socket.isConnected() should work), but there's nothing in the servlet spec that allows a servlet thread to obtain for that information. Ideally, the container (Tomcat) would asynchronously monitor the socket status and set some flag in the Request object for the webapp code to examine at its leisure. Might also be able to implement this with a new form of listener. I haven't looked at the Servlet 3 spec to see if anything is in there for this rather common problem. Hmm, last time I implemented a tcp/ip stack (which is more than 10 years ago) there were no possibility in the tcp protocol to detect a broken (not closed) connection except via so_timeout which should be large enough for a webapp to reply. As far as I know, socket.isConnected will never return false, once connected, even if you close the Socket on your side, isConnected will still return true. As for the OPs question (and i apologize if the answer was already given) the common approach to prevent f5-hitting users on long-running requests is to start a background thread which processes the request (or, more modern, use a Future and the Executor facilities) and return the current request back to the user with a waiting page, which refreshes itself in short periods checking whether the background task is yet finished and redirecting to the result page when done. regards Leon - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: [OT - question] Limit user sessions in tomcat
From: Leon Rosenberg [mailto:rosenberg.l...@googlemail.com] Subject: Re: [OT - question] Limit user sessions in tomcat Hmm, last time I implemented a tcp/ip stack (which is more than 10 years ago) there were no possibility in the tcp protocol to detect a broken (not closed) connection except via so_timeout which should be large enough for a webapp to reply. True, but the browser should be closing its end, which should result in a TCP RST being sent to the server, so the server's TCP/IP stack knows that further sends on that connection are not allowed. Whether or not that information is available down at the Java API level is dependent on the JVM/JRE implementation for the specific platform. - 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: [OT - question] Limit user sessions in tomcat
Caldarale, Charles R chuck.caldar...@unisys.com wrote in message news:99c8b2929b39c24493377ac7a121e21f9680850...@usea-exch8.na.uis.unisys.com... From: André Warnier [mailto:a...@ice-sa.com] Subject: Re: [OT - question] Limit user sessions in tomcat It would seem that there ought to be some low-level response-direction socket flag that should be available, to tell whether the receiving end has gone, without actually having to send anything from a higher-level code module. But getting to that low-level socket data does not seem to be so easy in Java, is it ? It's not hard in Java (Socket.getRemoteSocketAddress() or Socket.isConnected() should work), but there's nothing in the servlet spec that allows a servlet thread to obtain for that information. Ideally, the container (Tomcat) would asynchronously monitor the socket status and set some flag in the Request object for the webapp code to examine at its leisure. Might also be able to implement this with a new form of listener. I haven't looked at the Servlet 3 spec to see if anything is in there for this rather common problem. The Servlet 3 spec has something close: Asynchronous requests (which are sort of like Comet in TC 6). It's more designed to allow the servlet to push content to the client (think a JavaScript progress bar). - 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
