RE: How to limit concurrent requests by same user
When this has come up in the past, consensus seems to have been the setting of a unique token within the page when generated such that each time a user requests a submittable page, that page will contain a hidden attribute with that token. Implement a filter that only allows processing of that token once. I tried this approach once, I got stuck on this scenario: user submit a form, jsp/servlet processes and remove the token from list. But the user click abort before the page was transferred, thus leaving him with old token. He can't ever submit the page again. Anyone have think of a solution for this can please share? The problem with the solutions mentioned in this thread is that if a user double clicks on a form, the browser will display the output of the second click (which would be nothing). If you implement the tokens, the second request can wait for the first to complete, observing a result object that it can return once the first request finishes. This is *definitely* an advanced technique, but it's the most robust, user-tolerant, and resource-conservative one I've used and/or seen other places. Can you please share how to wait for first request to complete and grab the result? I'm really interested in this method but completely have no idea on how to implement. Depending on your situation, the simplest way I've seen to (mostly) handle this is to disable the submission button with Javascript once it's been tapped once. It's a point solution that's not perfect, but it'll catch 98% of egregious offenders. Tried this, same situation as above, submit and then cancel. (sigh) TIA. Antony - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: How to limit concurrent requests by same user
You just have to remove the token no matter what happens.
try {
// store token
// Do the processing and create output
} catch(SomeException ex) { // Optional
} finally {
// remove token
}
-Original Message-
From: Antony [mailto:[EMAIL PROTECTED]
Sent: Thursday, April 22, 2004 8:38 AM
To: 'Tomcat Users List'
Subject: RE: How to limit concurrent requests by same user
I tried this approach once, I got stuck on this scenario:
user submit a form, jsp/servlet processes and remove the token from list.
But the user click abort before the page was transferred, thus leaving
him with old token. He can't ever submit the page again. Anyone have
think of a solution for this can please share?
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: How to limit concurrent requests by same user
I think you misunderstood my problem. On first page I create a token and put
it on a map.
I then put the token as hidden fields in the page's form.
When user submit the page, I check if the token is still exists on the map.
If not then maybe the user pressed back on his browser and resubmit again,
or double clicked the link. (My application can handle this by returning a
*default* page based on its current value.)
If the token is on the list, it's removed and the a new token was created
and put on the list and on the form.
The cycles continues...
But this approach has a couple of flaws:
1. if user double clicked on a link: the same token was sent twice. The 1st
request processed by my app will never be seen by user, he only see the page
for the 2nd request, which is the *default* page. Suppose the 1st request
returned an error message or something he'll never see it.
2. if the user click Abort before receiving the response, he's stuck with
the old token which was *REMOVED* by my app, when it's processing the
request. The page that contains the new token was never received by the
user. He can't resubmit.
I hope it's clear (sigh) English composition is not my subject.. :(
I've not found any solution to this, so please if someone can share any
solution.
TIA
Antony.
-Original Message-
From: Ralph Einfeldt [mailto:[EMAIL PROTECTED]
Sent: 22 April 2004 13:49
To: Tomcat Users List
Subject: RE: How to limit concurrent requests by same user
You just have to remove the token no matter what happens.
try {
// store token
// Do the processing and create output
} catch(SomeException ex) { // Optional
} finally {
// remove token
}
-Original Message-
From: Antony [mailto:[EMAIL PROTECTED]
Sent: Thursday, April 22, 2004 8:38 AM
To: 'Tomcat Users List'
Subject: RE: How to limit concurrent requests by same user
I tried this approach once, I got stuck on this scenario:
user submit a form, jsp/servlet processes and remove the
token from list.
But the user click abort before the page was transferred,
thus leaving
him with old token. He can't ever submit the page again.
Anyone have
think of a solution for this can please share?
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to limit concurrent requests by same user
Put the token in the map only after the user submits the form. Then, when
you finish processing the results, remove it from the map, and create a new
token. Do not process a page if the token is already in the map.
(It sounds like you're doing the reverse - putting the token in the map when
you create the page, removing it when the user submits the form, and only
processing the page if the token is not in the map.)
- Original Message -
From: Antony [EMAIL PROTECTED]
To: 'Tomcat Users List' [EMAIL PROTECTED]
Sent: Thursday, April 22, 2004 4:45 AM
Subject: RE: How to limit concurrent requests by same user
I think you misunderstood my problem. On first page I create a token and
put
it on a map.
I then put the token as hidden fields in the page's form.
When user submit the page, I check if the token is still exists on the
map.
If not then maybe the user pressed back on his browser and resubmit again,
or double clicked the link. (My application can handle this by returning a
*default* page based on its current value.)
If the token is on the list, it's removed and the a new token was created
and put on the list and on the form.
The cycles continues...
But this approach has a couple of flaws:
1. if user double clicked on a link: the same token was sent twice. The
1st
request processed by my app will never be seen by user, he only see the
page
for the 2nd request, which is the *default* page. Suppose the 1st request
returned an error message or something he'll never see it.
2. if the user click Abort before receiving the response, he's stuck with
the old token which was *REMOVED* by my app, when it's processing the
request. The page that contains the new token was never received by the
user. He can't resubmit.
I hope it's clear (sigh) English composition is not my subject.. :(
I've not found any solution to this, so please if someone can share any
solution.
TIA
Antony.
-Original Message-
From: Ralph Einfeldt [mailto:[EMAIL PROTECTED]
Sent: 22 April 2004 13:49
To: Tomcat Users List
Subject: RE: How to limit concurrent requests by same user
You just have to remove the token no matter what happens.
try {
// store token
// Do the processing and create output
} catch(SomeException ex) { // Optional
} finally {
// remove token
}
-Original Message-
From: Antony [mailto:[EMAIL PROTECTED]
Sent: Thursday, April 22, 2004 8:38 AM
To: 'Tomcat Users List'
Subject: RE: How to limit concurrent requests by same user
I tried this approach once, I got stuck on this scenario:
user submit a form, jsp/servlet processes and remove the
token from list.
But the user click abort before the page was transferred,
thus leaving
him with old token. He can't ever submit the page again.
Anyone have
think of a solution for this can please share?
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
How to limit concurrent requests by same user
Hi, some of my JSP pages take a few seconds to process. When users get impatient and request them again, without having waited for the initial request to complete, load builds up rapidly, making everything even slower and taking down tomcat completely quite soon. Any ideas on how to prevent this? I already thought of setting an attribut in the session at the beginning of processing a page and removing it again at the end. Following concurrent requests by the same user (session) will first check if the attribute is present and just return a blank page, if it is. But what to do, if an user cancels the request, and the page isn't processed until the end, as it fails with an IOError? Isn't there any better way? I'm using Apache 1.3.29 + Tomat 5.0.19 + mod_jk2 2.04 Thank you! Thomas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to limit concurrent requests by same user
We just did this for our application. We do pretty much what you said, except with a little tweak. If multiple requests come in for the same session, all but the first request wait (literally: Object.wait()) until the first one has finished. We also keep a track of which was the last thread to come in the door. When the request being processed finishes, only the thread that was the last in the door gets processed. All other requests just get ended with no content (and hence minimal processor usage), because there's no browser waiting for the response anyway. Of course, this won't work if you want to support multiple browser windows attaching to one session. Graham. Thomas Lange wrote: Hi, some of my JSP pages take a few seconds to process. When users get impatient and request them again, without having waited for the initial request to complete, load builds up rapidly, making everything even slower and taking down tomcat completely quite soon. Any ideas on how to prevent this? I already thought of setting an attribut in the session at the beginning of processing a page and removing it again at the end. Following concurrent requests by the same user (session) will first check if the attribute is present and just return a blank page, if it is. But what to do, if an user cancels the request, and the page isn't processed until the end, as it fails with an IOError? Isn't there any better way? I'm using Apache 1.3.29 + Tomat 5.0.19 + mod_jk2 2.04 Thank you! Thomas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Graham Lea Software Engineer Forge Research Pty Ltd Suite G11, Bay 9, Locomotive Workshop Australian Technology Park, Cornwallis Street Eveleigh NSW 1430 Australia Phone: +61 2 9209 4152 Fax: +61 2 9209 4172 www.forge.com.au -- This message contains privileged and confidential information intended only for the use of the addressee named above. If you are not the intended recipient of this message you must not disseminate, copy or take any action in reliance on it. If you have received this message in error please notify the sender immediately. Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of another (including a Body Corporate). -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to limit concurrent requests by same user
Graham Lea wrote: We do pretty much what you said, except with a little tweak. If multiple requests come in for the same session, all but the first request wait (literally: Object.wait()) until the first one has finished. We also keep a track of which was the last thread to come in the door. When the request being processed finishes, only the thread that was the last in the door gets processed. All other requests just get ended with no content (and hence minimal processor usage), because there's no browser waiting for the response anyway. Of course, this won't work if you want to support multiple browser windows attaching to one session. One could keep apart requests not only by user, but also by URL. This should allow different windows, if they contain different pages. I wonder if it would be possible to write a filter that would implement this functionality transparently to the JSP pages/servlets. It's not only the users getting impatient, there is also a lot of (Windows) users that do double clicks on every web link (effectively doubling server load). Regards, Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to limit concurrent requests by same user
I wonder if it would be possible to write a filter that would implement this functionality transparently to the JSP pages/servlets. It could be done semi-transparently with a conditional custom tag embracing all of an individual page's content. That tag could check for concurrent request and then conditionally display or omit the (costly) body of the page. Regards Thomas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to limit concurrent requests by same user
You'll find quite a bit of info about this in the archives. When this has come up in the past, consensus seems to have been the setting of a unique token within the page when generated such that each time a user requests a submittable page, that page will contain a hidden attribute with that token. Implement a filter that only allows processing of that token once. The problem with the solutions mentioned in this thread is that if a user double clicks on a form, the browser will display the output of the second click (which would be nothing). If you implement the tokens, the second request can wait for the first to complete, observing a result object that it can return once the first request finishes. This is *definitely* an advanced technique, but it's the most robust, user-tolerant, and resource-conservative one I've used and/or seen other places. Depending on your situation, the simplest way I've seen to (mostly) handle this is to disable the submission button with Javascript once it's been tapped once. It's a point solution that's not perfect, but it'll catch 98% of egregious offenders. justin At 12:58 AM 4/21/2004, you wrote: I wonder if it would be possible to write a filter that would implement this functionality transparently to the JSP pages/servlets. It could be done semi-transparently with a conditional custom tag embracing all of an individual page's content. That tag could check for concurrent request and then conditionally display or omit the (costly) body of the page. Regards Thomas __ Justin Ruthenbeck Software Engineer, NextEngine Inc. justinr - AT - nextengine DOT com Confidential. See: http://www.nextengine.com/confidentiality.php __ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to limit concurrent requests by same user
Andreas Schildbach wrote: I wonder if it would be possible to write a filter that would implement this functionality transparently to the JSP pages/servlets. The solution I explained was coded in a filter. Justin Ruthenbeck wrote: The problem with the solutions mentioned in this thread is that if a user double clicks on a form, the browser will display the output of the second click (which would be nothing). The solution I explained will, for every sequence of concurrent requests on the same session, generate output only for the first and last requests in the sequence, ignoring all requests in between. The user should never see nothing (except in the multiple-window scenario I already pointed out). Graham. -- Graham Lea Software Engineer Forge Research Pty Ltd Suite G11, Bay 9, Locomotive Workshop Australian Technology Park, Cornwallis Street Eveleigh NSW 1430 Australia Phone: +61 2 9209 4152 Fax: +61 2 9209 4172 www.forge.com.au -- This message contains privileged and confidential information intended only for the use of the addressee named above. If you are not the intended recipient of this message you must not disseminate, copy or take any action in reliance on it. If you have received this message in error please notify the sender immediately. Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of another (including a Body Corporate). -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
