Re: [AOLSERVER] How does a module know a GET or POST request was cancelled?
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?
Re: [AOLSERVER] How does a module know a GET or POST request was cancelled?
Thanks Peter for your reply. What I'm trying to do, in fact is not GUI based at all. I am using AOLServer (and my module) as a way to establish a login session to some login server for my application. I have to keep the login session to the login server active for the duration of my application's clients. The need to "cancel a request" is based on the fact that my application's client can cancel it's session and I need to cancel the backend login session when that happens.I think your approach of "the initial request creating a "session id" and a worker thread" will work, so I'll try it. Thanks, Ramin. -Original Message- From: AOLserver Discussion [mailto:[EMAIL PROTECTED]]On Behalf Of Peter M. Jansson Sent: Wednesday, December 19, 2001 10:31 AM To: [EMAIL PROTECTED] Subject: Re: [AOLSERVER] How does a module know a GET or POST request was cancelled? 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?
Re: [AOLSERVER] How does a module know a GET or POST request was cancelled?
OK, that being the case, I'll recommend that you consider using a database pool and a faux database driver for what you're doing. This will work if you don't require that each visitor have a unique identity to your external system. In this case, AOLserver does a terrific job of managing a pool of external sessions, bringing them up or tearing them down as necessary, based on usage and idle patterns. I've used this method successfully on a few projects.
Re: [AOLSERVER] How does a module know a GET or POST request was cancelled?
On 2001.12.19, Peter M. Jansson <[EMAIL PROTECTED]> wrote: > 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. I agree, but you didn't recommend a third, very useful solution: Server push. Explanation and implementation is left as an exercise for the reader. -- Dossy -- Dossy Shiobara mail: [EMAIL PROTECTED] Panoptic Computer Network web: http://www.panoptic.com/ "He realized the fastest way to change is to laugh at your own folly -- then you can let go and quickly move on." (p. 70)
Re: [AOLSERVER] How does a module know a GET or POST request was cancelled?
The last time I looked at server push, there was one example on the netscape site, and it appears that the mechanism used is no longer widely supported by the browser. Can you point this interested reader to a better example? On Wed, 19 Dec 2001, Dossy wrote: > I agree, but you didn't recommend a third, very useful solution: > > Server push.
Re: [AOLSERVER] How does a module know a GET or POST request was cancelled?
On 2001.12.19, Peter M. Jansson <[EMAIL PROTECTED]> wrote: > The last time I looked at server push, there was one example on the > netscape site, and it appears that the mechanism used is no longer widely > supported by the browser. Can you point this interested reader to a > better example? One way of doing it (which isn't great, but it's easy to implement) is: http://aolserver.com/docs/devel/tcl/tcl-api.adp#ns_adp_stream Another way is hand-crafting your own HTTP response using multipart MIME, with each part being of type text/html (or whatever is appropriate). Every so often, before the timeout elapses, either send the keep-alive part (can't remember what it is off the top of my head) or your actual content part. -- Dossy -- Dossy Shiobara mail: [EMAIL PROTECTED] Panoptic Computer Network web: http://www.panoptic.com/ "He realized the fastest way to change is to laugh at your own folly -- then you can let go and quickly move on." (p. 70)
Re: [AOLSERVER] How does a module know a GET or POST request was cancelled?
Internet explorer does not, from my examination of the available literature, support server push, at least not in any way I could get it to work. However, I did notice that a meta refresh tag in the middle of a document is still (at least under some circumstances) honored, so what we did was: print out a "please wait" type page, with enough text that it gets written out right away. This was done with ns_write in an adp. start the long process when the process is done, send a (around 100 spaces) The refresh goes to the "correct" ending page. The point of this is, the page with the submit button is pretty much immediately replaced with the please wait page. If you don't do this, the page with the submit button hangs around until the long process is done, inviting the user to resubmit or cancel the job. The please wait page lets them know Something is Working. Having a "cancel" button on this page might be nice. Rusty -- Rusty Brooks : http://www.rustybrooks.org/ Spewing wisdom from every orifice --
Re: [AOLSERVER] How does a module know a GET or POST request was cancelled?
On Wed, 19 Dec 2001, Rusty Brooks wrote: > print out a "please wait" type page, with enough text that it gets written > out right away. This was done with ns_write in an adp. I suggested something like this earlier, although with an asynchronous worker thread. I think that better than "please wait" would be to offer an estimate of time remaining, or some other concrete progress implementation (% done), so the user has some idea how long to wait.
Re: [AOLSERVER] How does a module know a GET or POST request was cancelled?
On 2001.12.19, Rusty Brooks <[EMAIL PROTECTED]> wrote: > Internet explorer does not, from my examination of the available > literature, support server push, at least not in any way I could get it to > work. You're right. That sucks. However, I'm sure with IE you could trick out some kind of server push with a small ActiveX control. *chuckle* -- Dossy -- Dossy Shiobara mail: [EMAIL PROTECTED] Panoptic Computer Network web: http://www.panoptic.com/ "He realized the fastest way to change is to laugh at your own folly -- then you can let go and quickly move on." (p. 70)
Re: [AOLSERVER] How does a module know a GET or POST request was cancelled?
On Thu, 20 Dec 2001, Dossy wrote: > You're right. That sucks. However, I'm sure with IE you could > trick out some kind of server push with a small ActiveX control. ...or a Java applet, or a Tclet, or some other _non-HTTP_ solution. That's what I was saying -- HTTP is the wrong protocol for this. Doesn't mean HTTP isn't a good protocol, it just means it wasn't designed for this type of dialog control. Pete.
