Hi Tim, Currently it is only using servlet spec stuff, but this imposes a few limitations and some extra resource usage, if it became a valve in tomcat it could remove these limitations and extra resource burdens.
For this reason I was seeking approval from those involved with the tomcat dev work before I convert it. If people are fundamentally against the feature set or have a good technical reason for it being done differently or not done I am happy to listen. If it becomes a valve then the extra request/response object it holds on to can be recycled, the number of active threads should be reducable to 1 java thread per request instead of up to 2 per request, which is quite important for Linux users. As a valve with access to the real request object it can also deal with multi-part requests correctly and postpone the wait page until it is safe to deliver and will be able to flush the buffers to cause a much smaller wait page to be sent. The thing I am most keen for is that it or some alernative code that does the same is taken up and maintained as I have found no generic application-transparent implementations of a busy page or don't press that button again functionality. Pete > If your using Servlet spec features only - move this to tomcat-user. As > for > including the functionality in tomcat, my preference is no since it is not > tomcat specific and can be used by any container. If thats the case - it > might be better as a Sourceforge project. ... Unless we create a > subproject > under tomcat for contributions such as utilities, alternative OS startup > scripts, etc (But not make it prt of the default distribution) > > -Tim > > [EMAIL PROTECTED] wrote: > >> 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. >> > > --------------------------------------------------------------------- > 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]
