On Wed, Feb 18, 2009 at 2:04 PM, david_data_digga
<[email protected]> wrote:
> In most cases I'm finding that a
> com.google.gwt.user.client.rpc.StatusCodeException
> is thrown with status code 12029, which is appropriate and what I'd
> like to have happen all the time.
>
> However, in a few cases, these calls seem to be getting queued and
> then get passed to
> the server once the server is back up.
>
> What could account for this different behavior in different
> situations?  I presume there must be
> some setting somewhere to adjust this but I haven't been able to find
> it.

I can't really answer your question directly, but I'll try to fill you
in on some details, in case that answers it indirectly.

RPC is built directly on top of XMLHttpRequest (xhr).  As far as I
know, using an xhr instance to speak HTTP to a server is exactly the
same as typing a URL in the URL bar of your browser and initiating an
HTTP connection that way.  If the server is down but comes back before
the browser "gives up", you'll eventually get a response.  If the
browser gives up before the server comes back, you'll get some kind of
timeout or unreachable server exception.

As far as I know, browsers give up on HTTP connections after a timeout
has expired and the length of the timeout is either built-in or
configured via browser-specific UI.  In other words, the timeout is
not, AFAIK, configurable from script.  On the other hand, you could
set up your own timeout that invokes the cancel() method on the
in-flight xhr to cancel a request "early".  You can get at the xhr
that undergirds your RPC request by declaring the relevant method on
your async service interface to return RequestBuilder instead of void.
 (I'm not 100% sure that RequestBuilder is the right type name.  This
subject has come up at least once before on the mailing list, though,
so, if I'm wrong, trying searching the history.)

I think there are some caveats regarding using cancel().  I'm not 100%
sure, but I think, if the response is already on the way, the callback
may be invoked even though the request was canceled.  I'm not sure if
there's a work-around, or even if there's any built-in way to discover
that the response you're handling has been canceled.

Ian

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"Google Web Toolkit" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to 
[email protected]
For more options, visit this group at 
http://groups.google.com/group/Google-Web-Toolkit?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to