so i forgot one detail... while the "cancel-able" process is running, the user can navigate around and do whatever else they want, except kicking off an additional "cancel-able" process. thus, since they could be kicking off various other servlets, i dont want to stop any of that processing. the only thing i want to monitor and kill if they hit the cancel button is the original "cancel-able" servlet processing...
i guess i will start playing around with java threads where one is doing the processing and a 2nd one is writing NULL bytes to the client until it bombs. and if and when it bombs, it would interrupt the processing thread and then the servlet would return...
thanks again!
On 6/29/06, Michael Peters <[EMAIL PROTECTED]> wrote:
Brian Dinsmore wrote:
> 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...
It doesn't matter that the you put the data in the session. You can still
periodically write a null byte to the client. Sending a null byte doesn't show
anything on the client, all it will do is check the socket connection.
If you wait to check this connection after you're done with your processing,
then you're not saving anything.
--
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
