tags:

views:

474

answers:

2

I'm using RequestBuilder to time out GWT requests which take too long:

RequestBuilder requestBuilder = _service.getStatistics(callback);
requestBuilder.setTimeoutMillis(5000);
try {
    requestBuilder.send();
} catch (RequestException e) {
    GWT.getUncaughtExceptionHandler().onUncaughtException(e);
}

Is there a way of notifying the invoked remote service that the call has timeout out on the client and that it should be cancelled?

+4  A: 

Not unless you make another call to tell the remote service that the previous call was cancelled!

Chii
Thanks for the answer. I'm still hoping for another solution :-)
Robert Munteanu
You could try looking at this http://stackoverflow.com/questions/585599/whats-causing-my-java-net-socketexception-connection-reset and see if anything can be used on the serverside - e.g., if you catch some sort of connection reset exception. It'd be pretty hacky, and i wouldnt reocmmend this sort of thing. If you really need to tell the server that the prev call timed out, it wouldnt be too bad to do another call - as long as its quick and fast.
Chii
on the server side, set a dirty flag to false when the initial request comes in. Add a timer to that server side class that is processing the request. If the timer runs out before the request is provided, then set the dirty flag to true, and return that info, or make a separate http request from the timer in your server side class.
kr
+1  A: 

This actually depends. If the server is doing a lot of work (and you are not on Google App Engine) you can keep the Request around and call request.cancel(). This will end the browser's request, but the server will keep working.

Depending on the format of the data you are returning, you can have the server flush some empty data to the client periodically while the call is processessing. This will cause the flush to throw an IOException if the client has cancelled the request and the HTTP connection is terminated. You can then catch this request and stop processessing the request on the server side.

kebernet
Thanks for the answer, it is useful. This is the so-called long polling pattern if I'm not mistaken. I'm still hoping for something simpler.
Robert Munteanu
It is a similar idea to long poll eventing, but the pattern also works well for ending long processes. There can be other things you can't easily stop -- a call to a slow DB procedure won't terminate unless you actually close a connection, rather than just returning it to a pool. One trick I have used before: If you have a ton of stuff to accomplish in a service call, spin up a thread pool executor, and make every Nth Runnable (where N is the size of the thread pool) flush a little data to the client. This will let you, give or take, make sure you don't execute more than 2N-1 extra tasks.
kebernet