tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <ch...@christopherschultz.net>
Subject Re: Limit user sessions in tomcat
Date Tue, 15 Dec 2009 18:30:21 GMT
-----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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message