alrighty, that totally makes sense that the client cant really kill a server process... my issue is that the process on the server normally completes by writing the results of it processing to the user's session which is ultimately used to drive what is seen on the page when they hit our custom "refresh" button.... thus, i need a way to kill the process or tell the servlet to not write its results to session so the user wont see the results of the process they think they cancelled...
i think i will write a ignore variable to session upon aborting the request and then have the "aborted" servlet check the ignore variable before it writes to the user session...
thanks for the info!
Brian
On 6/29/06, Michael Peters <[EMAIL PROTECTED]> wrote:
Brian Dinsmore wrote:
> im using an Ajax.Request to hit a java servlet and do some processing.
> during this time, if the user feels the process is taking too long,
> he/she can hit a cancel button to kill the request... by calling the
> * abort* function off of the transport, will that kill the processing
> that my server is doing as well or just make the client think that the
> process has ended?
No it will not. There is no way for the client to tell the server to kill a
process. That would be a real security issue. If your process has the option of
being cancelled by the client and you want to stop it from processing, you have
to handle that your self. It's the exact same issue as using the "Stop" button
(or even "Reload") on normal requests.
How you handle it depends on your server side technology, and depending on what
you use, it may not be possible since your framework may not allow access to
such low level stuff (TCP socket connections).
Since there is no way to detect if a connection has been closed by the browser
except to write to the socket the technique follows something like this (under
Apache/mod_perl).
Periodically while calculating or processing we write a NULL byte to the socket.
If the client canceled, then we receive a SIGPIPE signal from Apache. We then
stop processing and cleanup anything we need.
HTH
--
Michael Peters
Developer
Plus Three, LP
_______________________________________________
Rails-spinoffs mailing list
Rails-spinoffs@lists.rubyonrails.org
http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs
_______________________________________________ Rails-spinoffs mailing list Rails-spinoffs@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs
