This is a variant of your worker-thread problem from earlier, isn't it? I'll begin with a sermon -- if you brought your hymnal, please turn to the appropriate page; if you don't want to be bored by my opinion, please skip to the next paragraph. Worker threads and progress notification are a hallmark of modern UI design, and help give users of software feedback on the progress of the system. The problem is that these devices require an underlying mechanism that provides adequate latency for issuing progress notification. HTTP is terrible at doing this, because the protocol is designed to be silent between request and response, this denying the application author the opportunity to let the visitor know what's going on -- you can't talk to them until you're done. In short words, the Web ain't Windows. It is customary and acceptable on the web to provide a warning before the visitor hits the "big long request" button that "this will take a while -- go get coffee/soda/Tolstoy" so you can just do the request and let the visitor take the consequences. It's not the best UI design, but it is pretty good client-server design. If you really need to control the dialog with low latency, you need a client other than a web browser. Again, this entire paragraph is my opinion, and you're welcome to disagree. Now to solutions:
If you were to just generate the data and return it through a normal ns_return (or through an .adp), and if the output channel were to die because the visitor cancelled the request, AOLserver would discard the data. Your process will have spent time and money generating the data, but is it otherwise harmful? One problem I can think of with this approach is that you might get an inadverdent denial-of-service from folks who think the system is just slow, and keep hitting reload. In this case, you could have an nsv counter for a number of processors you want to allow; increment when you start generating, decrement after; if too many are in process (you would need to define "too many"), then you could return a "too busy -- try later" page to the visitor. If you really want to control the dialog with the visitor then one approach would be to go back to your worker-thread approach, but the worker-thread doesn't return anything to the visitor. The initial request generates a request ID and sends a page with a refresh back to the visitor that says something like "click here to get your results, or your browser will automatically check for them every n seconds". On subsequent refreshes, you can just display the same request to the visitor, or you could give them an option to "click here if you're so bored you don't care anymore," in which case you could signal the worker-thread somehow that it can stop now and release its resources. On your intermediate status page, you could even display a progress notifier that could show what percent of the data generation is complete, if you have that information. This approach avoids the immediate denial-of-service, because you give more immediate feedback, but you might still want to constrain how many worker threads you are willing to spin off, using an nsv counter again. On Wed, 19 Dec 2001, Ramin Naimi wrote: > Is it possible for a module to get notified that a GET or POST request was > cancelled by the client? My procedure will take a long time to process and I > would like to know (during processing) if the request was cancelled. I > suppose I can do a Ns_ConnPuts during my processing and check for it's > return value and assume that if it failed then the request was cancelled. Is > there a more cleaner way?
