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?

Robert Munteanu
  • 67,031
  • 36
  • 206
  • 278
  • Is your `_service` async interface's method? If yes, how then you specify method and url for request builder? – maks Jan 06 '12 at 09:17

2 Answers2

5

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

Chii
  • 14,540
  • 3
  • 37
  • 44
  • Thanks for the answer. I'm still hoping for another solution :-) – Robert Munteanu Aug 14 '09 at 12:24
  • 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 Aug 14 '09 at 12:28
  • 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. Mar 04 '10 at 21:01
1

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
  • 192
  • 1
  • 6
  • 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 Aug 20 '09 at 19:53
  • 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 Aug 20 '09 at 21:06