2.4 RPC failure

Skip to first unread message

John Malpas

Mar 30, 2012, 12:29:21 AM3/30/12
to google-we...@googlegroups.com
I have several apps out there written in GWT 2.4
Over the last few months, users have started to complain
about seemingly random RPC failures, both reading and writing.
I have never yet experienced these errors from my own computer,
but there are enough users writing in about it that
it seems that there must be something going wrong -- not just
one user with a questionable internet connection.

The manifestation in the onFailure() method of an AsyncCallback
is usually
  com.google.gwt.user.client.rpc.StatusCodeException: 0

I found one cooperative user who has been willing to beat on the
apps for me and send me results.He gets the errors with Firefox 8, IE 8,
and Chrome.When the RPC calls work, I see custom log messages in
the tomcat log. When the calls do not work, I see no evidence of any activity
in either the tomcat log or the apache log, so it appears that the RPC
calls are not reaching the server.

This morning I changed one of the apps to include a symbol table,
and to print out a stack trace in a dialog when the failure happens, and then
asked my precious user to try it. He sent back this stack trace,
copied from the dialog:

fail to write
CAUGHT com.google.gwt.user.client.rpc.StatusCodeException: 0
0 : Unknown.Em(StackTraceCreator.java:168)
1 : Unknown.Jl(StackTraceCreator.java:421)
2 : Unknown.RF(StatusCodeException.java:35)
3 : Unknown.bH(RequestCallbackAdapter.java:209)
4 : Unknown.bs(Request.java:287)
5 : Unknown.Bs(RequestBuilder.java:395)
6 : Unknown.anonymous(XMLHttpRequest.java:287)
7 : Unknown._l(Impl.java:168)
8 : Unknown.cm(Impl.java:213)
9 : Unknown.anonymous(Impl.java:57)

In broad strokes, I understand that the exception is
thrown because the browser is unable to do an XMLHttpRequest.
But more than that, why? I have looked up the line references
in the 2.4 source modules mentioned in the stack trace above,
but am still at a loss. The last one is this:

 public final native void setOnReadyStateChange(ReadyStateChangeHandler handler) /*-{
    // The 'this' context is always supposed to point to the xhr object in the
    // onreadystatechange handler, but we reference it via closure to be extra sure.
    var _this = this;
    this.onreadystatechange = $entry(function() {
 287:     handler.@com.google.gwt.xhr.client.ReadyStateChangeHandler::onReadyStateChange(Lcom/google/gwt/xhr/client/XMLHttpRequest;)(_this);

Any suggestions would be greatly appreciated.

Boris Lenzinger

Mar 30, 2012, 3:12:13 AM3/30/12
to google-we...@googlegroups.com

I have written an application and few month ago I got this error message : com.google.gwt.user.client.rpc.StatusCodeException: 0
At last I found an explanation (for my case which might not worth for yours but can give you ideas maybe).

I am developing my app on my laptop. So at home I have a network connection (I use wireless connection). Then I suspend my laptop (that has at this time an ip address and a network environment). When I am at my customer site, I then resume my laptop. No wireless network and not cable network available for people from outside but I didn't disable my previous network configuration. Then I try to connect to my app with my browser. So the browser is doing a call on a local machine with http://localhost:8080/blabla. And there this message is raised !
After it happened a few times, I tried the following : disable wireless on my laptop. Then the network configuration is changed. I just have a And then I don't have anymore the error message.

Are your users on laptops or desktops ? Are they connected with cable or wireless ? I don't know if this can match your case or not but may be the problem is really related to their network connection (may be lan).

Hope this can give you some ideas to find out what your problem is.


You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/2TVvDKQzwkkJ.
To post to this group, send email to google-we...@googlegroups.com.
To unsubscribe from this group, send email to google-web-tool...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.

Thomas Broyer

Mar 30, 2012, 5:58:14 AM3/30/12
to google-we...@googlegroups.com
A status code of 0 is symptomatic of network errors (or if you unload the page –navigate away or reload– while there are pending RPC requests: they'd be aborted with a status code of 0), so it's expected that you don't see anything on your server logs: the requests aren't reaching it.
Now so as to understand why this is the case, I don't have a single idea, sorry. It might be proxies/firewalls blocking them (maybe they don't like the GWT-specific custom content-type and/or headers), or real connectivity issues.

John Malpas

Mar 30, 2012, 12:08:55 PM3/30/12
to google-we...@googlegroups.com
Thomas and Boris thanks for your comments.

Here are a few more details.

It is very hard to test, because it does not happen for me.
I have even trotted my laptop around to various cafes /
wireless environments trying to provoke the problem,
but I have not yet experienced the problem.

It is not SOP, because the web page and the web server
are coming from the same domain + server.

It is (seemingly!) random. I have talked to two users to verify this.
When an RPC call fails (e.g writing a record), if they try the same
call a few seconds later, it might succeed.

One of the apps subject to this problem has been in production
since 2008. This problem has appeared only recently. I think the
first time a user wrote in about was in Dec 2011, and since I could not
replicate what he was talking about, I attempted to dismiss it as
related to his strange bad internet connection. Since then many
users have reported it. There have been certain days when it
seem to happen a lot.

I have some tried some weird stuff, like iterating on the RPC
call while it is failing (try - fail - wait - try again ... 4 times).
I can't tell if this ever does any good, but from what the user
told me yesterday, sometimes it goes through 4 tries
without succeeding.

Joseph Lust

Mar 30, 2012, 12:14:55 PM3/30/12
to google-we...@googlegroups.com

Sounds like a network connection error, which will always be a failure mode for web apps and a SOB to debug. Perhaps it would be easiest to catch this error in the onFailure() call of your RPCs and display a message to the users telling them to check their connection or reload the page? That's what we do in our apps. We also have a logger RPC that mails any such error traces home, but if it is a network issue, you probably won't get those.

Hope that helps,

John Malpas

Mar 30, 2012, 12:51:14 PM3/30/12
to google-we...@googlegroups.com
SOB to debug is right!

I do have the message asking them to reload the page,
but I am afraid that many of them get discouraged by
the initial error.

However, putting the stack trace in a user dialog is having
some beneficial effects (at the cost of making us appear
totally incompetent) -- I received this from a user this morning:

Please refresh the page
Update ERROR(41): fail to write
CAUGHT com.google.gwt.user.client.rpc.InvocationException: Unable to initiate the asynchronous service invocation (WeedDataService_Proxy.writeXRecord) -- check the network connection

CAUSED BY com.google.gwt.http.client.RequestPermissionException: The URL http://www.calflora.org/.... is invalid or violates the same-origin security restriction
CAUSED BY com.google.gwt.http.client.RequestException: (Error): Access is denied.

So that looks like it is an SOP error, in spite of the
servlet being on the same domain as the webpage.
I will look at the generated WeedDataService_Proxy
class to see if anything looks amiss.

John Malpas

Mar 30, 2012, 4:48:52 PM3/30/12
to google-we...@googlegroups.com

One of the users actually figured it out
(at least one variation) --
this is crowd sourced software development.

As I wrote them, the ServiceDefTarget classes force
the service entry point to be the domain name
including "www".

So if a user went to a webpage in our domain, but
without the "www", then the various browsers would
interpret the webpage as being in a different domain
from the call to the server -- therefore
a violation of SOP.
Reply all
Reply to author
0 new messages