The For my GWT RPC calls, I create a RequestBuilder with a timeout, so the
caller knows if the request never came back, and can deal with
the consequences. Ie:
public static RpcRequestBuilder createRpcRequestBuilder(int timeoutInMs) {
return new RpcRequestBuilder() {
@Override
protected RequestBuilder doCreate(String serviceEntryPoint) {
RequestBuilder builder = new RequestBuilder(RequestBuilder.POST,
serviceEntryPoint);
builder.setTimeoutMillis(timeoutInMs);
return builder;
}
};
}
On Saturday, 15 November 2025 at 6:28:03 am UTC+11 Bob Lacatena wrote:
> I work on a web app which is a multi-user simulation used in training. As
> such, we have a wide variety of users, but the simulation is very
> interactive, with the "players" making decisions that are recorded on the
> backend, update the business model, and then reflect changes in everyone's
> user interface (browser).
>
> A lot of work has gone into keeping things in synch among 100+
> simultaneous users. In particular, many users have bad Internet connections
> (since the pandemic, many use horribly configured home networks) so extra
> effort is put into detecting message failures, retrying, or alerting users
> that their communication with the server is inadequate (so they don't think
> things are working when they aren't).
>
> In particular, we now have more and more Safari users, and Safari does not
> handle connections, connection pooling, and error reporting the way that
> Chrome or Firefox (or Edge) do.
>
> Safari will occasionally show the following error in the browser console:
>
> [Error] Failed to load resource: The network connection was lost.
> With respect to GWT requests, Safari often *doesn’t deliver a normal
> onreadystatechange with a status code*; instead it fires the XHR *onerror*
> (or onabort/ontimeout) path with status === 0. RequestBuilder doesn't
> detect this,, so our code is not detecting situations where a request fails
> in this way.
>
> [We detect this in Chrome because it will normally throw a
> StatusCodeException with a status code of zero.]
>
> [*According to ChatGPT...*] This happens often with Safari because
> Safari/WebKit
> is pretty aggressive about reusing TCP connections, and so can randomly
> throw this at any time it tries to reuse a connection that has gone stale
> (it apparently doesn't detect the problem and try a different connection
> itself).
>
> We have seen this behavior happen a lot, to the extent that we basically
> can't allow users to use Safari with our web simulations.
>
> I have some suggestions from ChatGPT (which I really don't trust much)
> that we can take action on to try to detect this edge case (no idea if it
> will really work), *but it would be far simpler if this was built into
> GWT and the RequestBuilder *(and possibly translated into a
> StatusCodeException or some other special construct that is
> browser-agnostic)*.*
>
> NOTE: There is no urgency to this "request". Our current off ramp is to
> just tell clients that users may not use Safari. But I'd love it if you
> solved the problem for us (someday).
>
--
You received this message because you are subscribed to the Google Groups "GWT
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion visit
https://groups.google.com/d/msgid/google-web-toolkit/7f73e434-d62e-4ff6-88c2-e5f4e6b53584n%40googlegroups.com.
