Hi David, The method is quite simple, the filter notices requests on the way in, and ties up sessions to currently running requests/URL's. The response/request are wrapped to allow caching of the response(no data is sent to the user until the request finishes processing, this can be changed but I don't see a good reason to do it, it's most stable this way round, large responses can be written to disk so the memory overhead is minimal) then the incomming request is added to a list of those running for the sending of a please wait page if needed.
If a user sends a second request and both the first and second request are not allowed to run concurrently the original wrapped response has it's response object replaced with the new one so the original request can still be serviced. This second request is then sent to sleep awaiting the completion of the original request and does no further processing, one of the changes I want to make is to send the original response object back to be recycled and closed, but this needs pretty tomcatish access so it's not done yet. A third or subsequent request will release the previous request so it is recycled properly, however there will always be 2 request/responce pairs open until I gain the ability to recycle the unused original response and 2nd/3rd/... request. If the original request takes longer than a definable period then a please wait page is sent to the user, but the response stream is not closed until the proper request has completed, this page includes a metarefresh to the original URL which will be caught by the filter when the page refreshes and cause the sending of the proper response. If the browser times out then the metarefresh kicks in and causes in effect a second request to the URL so simply causes the please wait page to be resent and replaces the live response object with this new one allowing the original request to still process correctly. Safari on a mac is the only browser I've tested that even notices this, you get a pop-up that allows warns you of the timeout. As a running request finishes and returns through the filter the cached response data is posted back if the wrapped response hasn't been used. If the wrapped response has been used to send a wait page then no data is sent until that wait page refreshes with the metarefresh it contains internally. Data about state of a request is stored in the session object so there is a chance for a clash in the names used to store session objects, these names can be changed in the filter config however. Typically I implement the please wait functionality as 2 pages, the main please wait page with a frame/iframe inside. The iframe updating regularly to allow status messages using javascript and the outerframe with the metarefresh tag that will cause an update only when the page has been completed which is after the original request finishes. The application need have no knowledge of the filter and I have successfully fitted this to 3 apps in the last couple of weeks using Tomcat 4 and 5. The filter config in the web.xml and the jar containing the filter are the only things that need to be put in place. For pages that cause problems you can exclude them completely, so far I've only done this for framesets on one app because the graphics they wanted on the pleasewait page looked rubbish if they were scaled and the pages were generally held to be fast enough to do without user feed back. Hope thats enough information, I would love to see this in tomcat as a base feature, it seems that lots of people have problems like this and I couldn't find a generic solution out there. Pete > > Peter, > > I'm very interrested in this. > how does it work ? > does it send the request as normal then only set the 'ive finished' flag > to true when its got the end of the content > from the orig request ? > > does the application care / notice ? > > tell me more ! > > Kind regards > David Cassidy > > > > > [EMAIL PROTECTED] > arning.com To: > [EMAIL PROTECTED] > cc: > 27/10/2004 09:23 Subject: method to protect > webapps from users > Please respond to > "Tomcat > Developers List" > > > > > > > hi guys, > > I'm new to this list, but a long time user of Tomcat. For a long time now > I've had a problem which I'm sure most of you are familiar with ; users. > > As always happens with any app in development the final tidy up stuff gets > left too late and some stuff gets missed out. The bit in this case was > holding screens for long running requests. > > I've written a filter which will take any request and after a defined > period of time send a generic "please wait" page, after the original > request has finished it will then forward the proper response. > > To get this to work properly there is an extra benefit, it can in a lot of > cases stop double clickers by ignoring requests that have been defined as > those not supposed to run concurrently for a given session. > > My current implemntation is container agnostic which I'm not really happy > with as it means the "please wait" page must be large enough to force a > send of the data though the response stream, however I'm loathe to hack > into the tomcat code to get low enough to fix this unless it is part of > tomcat. The second problem is detecting multi-part requests and not > allowing the "please wait" page until the multi-part data has been > gathered, currently I just exclude those requests, again a lower level > access would allow this to be fixed properly. > > Is this filter or a derivative something that would be of interest? > > The basic features that I've implemented are : > > please wait page after some defined period with no user coding > Multiple concurrent request per session selectively disabled by URL > > I can post the code or distribute however people want if this is something > you are interested in. > > In live web-apps I've found this invaluable as users don't get web-apps > and are very impatient, even if the problem is their dodgy old modem or > asking an app to do something it was never designed for. > > Before anyone says it I know this is a complete perversion of everything > that is supposed to happen in a web-app, however in the real world users > won't wait 5 seconds for anything unless they are being told it's under > way and I've never got holding screens in all the right places yet. This > covers them all and where possible reduces the ability of a single user to > submit 100 concurrent requests by hammering a submit button in > frustration. > > Any feed back is most welcome > > Thanks > > Peter Mengell > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > -- > > This e-mail may contain confidential and/or privileged information. If you > are not the intended recipient (or have received this e-mail in error) > please notify the sender immediately and destroy this e-mail. Any > unauthorized copying, disclosure or distribution of the material in this > e-mail is strictly forbidden. > > > > --------------------------------------------------------------------- > 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]
