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? right now i cant seem to get the servlet to stop processing even though the abort method has been called, im starting to think the abort method isnt the magic bullet that i was lazily hoping for.... can anyone help me out? my call looks like this to kick off the process for the user: var myRequest = new Ajax.Request(... blah blah); and inside my cancel function, it looks like this: myRequest.transport.abort(); thanks for the help! BD _______________________________________________ Rails-spinoffs mailing list Rails-spinoffs-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs
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? right now i cant seem to get the servlet to stop processing even though the abort method has been called, im starting to think the abort method isnt the magic bullet that i was lazily hoping for.... can anyone help me out? ------------------------------------- I haven''t had to do anything like this (yet), so I am not much help, but I will be interested in following this thread. On this note, I have no idea if server-side SQL scripts are aborted if a user hits the "stop" button on a browser before the page is fully loaded. Sam _______________________________________________ Rails-spinoffs mailing list Rails-spinoffs-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs
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
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 <mpeters-aUYv5hkjw45l57MIdRCFDg@public.gmane.org> 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-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs >_______________________________________________ Rails-spinoffs mailing list Rails-spinoffs-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs
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
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 <mpeters-aUYv5hkjw45l57MIdRCFDg@public.gmane.org> 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-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs >_______________________________________________ Rails-spinoffs mailing list Rails-spinoffs-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs
Brian Dinsmore wrote:> 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...This should still work. Sending back null bytes to the client won''t interfere. All it does it check to see if the connection is still there. This null byte will be recieved by the Ajax.Request object that you created for the original operation.> 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...Let us know what you find out. -- Michael Peters Developer Plus Three, LP
so the only question i have about sending the NULL byte is how the Ajax.Request knows that it shouldnt enter the onComplete function when it receives the NULL byte... how do you make sure that it still waits for the processing servlet to respond to it? On 6/29/06, Michael Peters <mpeters-aUYv5hkjw45l57MIdRCFDg@public.gmane.org> wrote:> > > > Brian Dinsmore wrote: > > 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... > > This should still work. Sending back null bytes to the client won''t > interfere. > All it does it check to see if the connection is still there. This null > byte > will be recieved by the Ajax.Request object that you created for the > original > operation. > > > 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... > > Let us know what you find out. > > -- > Michael Peters > Developer > Plus Three, LP > > _______________________________________________ > Rails-spinoffs mailing list > Rails-spinoffs-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs >_______________________________________________ Rails-spinoffs mailing list Rails-spinoffs-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs