Hi, everybody, I have a servlet that is doing heavy data crunching. The structure of my web application is like this: JSP1--> Servlet---> (Request Dispatch) JSP2 The JSP1 will invoke the Servlet, which does all number crunching and then dispatch to the JSP2 for presentation to the web browser. My problem is that if a user clicks the STOP button, or simply closes the browser, my Servlet will continue to run because it has no way of telling whether the user is still waiting for output. This gives me two headaches: 1. it consumes computing resources because the user doesn't need the result anymore. 2. it causes exception to be thrown out since there is no place for the output data. What I need is a way to alert the servlet when the user clicks the STOP button in the brower or completely exits the browser. Any help, please? Sam
Seems to me you should get an IOException because the socket is closed, but I don't think it will happen until you actually write some output. Maybe your servlet should be writing (and flushing) small chunks of HTML to check that the user is still there. Bill
Hi Bill, You are exactly right. I would get an IOException when the servlet/JSP try to write the things out. Your suggestion is also useful if I don't use the so-called servlet centric design, in which my servlet will not output anything, all the output (presentation phase) will be handled by the JSP dispatched by the servlet. However, my problem is to detect that the user is not interested in the work of the servlet thus to stop the running of the servlet. Keep in mind that in my servlet I cannot output anything information, otherwise I will not be able to dispatch. My intention is to detect that the user has pressed the STOP button (does it mean that the session is also invalidated at the same time) and then to "return". Any other way to detect such an event as pressing STOP button?
Hi! I think there is no way to detect if the user presses the stop button, exept, the browser will send this event as a request to the server and you have to identify him to stop the servlet. Http is a stateless protocoll so the session will not be invalidated until the user resubmit his data, or you send an answer. Mike
Win the opportunity to make money on the Internet<br /><a href="http://sweeps.sitesell.com/minirich.html" target="_blank" rel="nofollow">http://sweeps.sitesell.com/minirich.html</a>
HTTP is not only stateless, it's message-based. There are, however, no messages for "button-press" events and the like as in a regular GUI / client-server app. This keeps overhead low and browser independence high. What the "STOP" button REALLY means is "STOP the output" - it breaks the pipeline connection that the server was using to send the response back to the client. If by some wierd quantum mechanical effect the client disappeared while the server was calculating, the server wouldn't even be capable of noticing - it's only when it comes time for output that the client has to be there. There's the implication here that whatever you are calculating takes just long enough to be annoying, but not so long as to cause the browser to time out. That, obviously, could change if you started to scale up requests. I'd like to be able to suggest a solution, but about the best that come to mind are safeguards. Make it hard for the client to trigger calculations frivilously (that is, do things like ask "Are you sure?"). Consider offloading the calculations to another server where the wasted horsepower isn't such an issue. Or better yet, see if you can offload all or part of the heavy-duty stuff to run on the client's machine. It will be easier to attach a "Cancel" button there, and if not, at least they won't batter your server!
An IDE is no substitute for an Intelligent Developer.