how to test GWT app through a proxy

111 views
Skip to first unread message

John Malpas

unread,
Feb 25, 2012, 3:40:09 PM2/25/12
to Google Web Toolkit
I have several GWT (2.4) applications out there.

One in a while, a user writes in with a problem,
where it is clear the RPC is not working, and it
is clear there is some proxy involved in their access
to the application.

(Most recent: "Unable to initiate the asynchronous service invocation
(MyDataService_Proxy.login)")

I need to figure out some way to test access to the
applications through a proxy, so I can at least see what
these users are seeing. The same applications work fine
for me on a variety of browsers and computers.
(My own computers get to the web through ATT DSL with
no proxy involved.)

Has anyone else faced this problem (need to test through
a proxy)?

Dan

unread,
Feb 26, 2012, 10:20:11 AM2/26/12
to Google Web Toolkit
That error message suggests a different kind of proxy,
http://en.wikipedia.org/wiki/Proxy_pattern.

John Malpas

unread,
Feb 27, 2012, 1:56:32 PM2/27/12
to Google Web Toolkit
Thanks that is interesting. What I know is,
I am writing the "MyDataService" part, and somehow
GWT must be writing the "MyDataService_Proxy" part.

And then there is this one (thankfully) very vocal
user, whose access to the RPC needed by the application
goes through the "MyDataService_Proxy" part,
and it works for him only occasionally.

I would like to be able to test the "MyDataService_Proxy"
part from where I am developing, or at least from
somewhere nearby.

On Feb 26, 7:20 am, Dan <d.j.mcgr...@gmail.com> wrote:
> That error message suggests a different kind of proxy,http://en.wikipedia.org/wiki/Proxy_pattern.

JoseM

unread,
Feb 27, 2012, 2:43:05 PM2/27/12
to google-we...@googlegroups.com
I don't think it's directly related to the proxy pattern that Dan mentioned.  It seems to be that your user doesn't have great internet access, or there is some issue in the connection between that user and your web server.  It seems that the error message happens when the browser is not able to communicate (reliably) with the web server.

John Malpas

unread,
Mar 13, 2012, 7:11:48 PM3/13/12
to google-we...@googlegroups.com
The problem is getting worse, Now several users have sent me
similar errors, all on the new version of an app that has been
running (I thought reliably) for 1 1/2 years.

The error is like
Class$yE: Unable to initiate the asynchronous service invocation (MyDataService_Proxy.readRecords) -- check the network connection

And the same apps continue to work fine for me
on my internet connection.

So somehow GWT RPC is failing for some class of users out
there. Very confusing. I look at tomcat logs and apache
logs and I see no activity corresponding to the time when
the failure happened.

Jens

unread,
Mar 13, 2012, 8:25:47 PM3/13/12
to google-we...@googlegroups.com
MyDataService_Proxy is generated by GWT and you can see the generated files by adding "-gen <folder>" to your app's Eclipse run configuration.

The exception you see is thrown in RemoteServiceProxy.doInvoke(...) and simply wraps a possible RequestException. These RequestExceptions can be thrown by RequestBuilder.doSend(..) and are wrappers for JavaScriptExceptions that can be thrown by the browser if it can not do an ajax request using XMLHttpRequest.

All these exceptions are chained together so you should log the whole stack trace to get some more information.

I don't think its an issue in GWT-RPC. Its just that your customer's browser sometimes can't establish a connection to your server through a proxy. Maybe you can ask them to look through their proxy log files to see if something went wrong.

-- J.

John Malpas

unread,
Mar 27, 2012, 1:30:15 PM3/27/12
to google-we...@googlegroups.com
Thanks Jens for your pointers. Here are a few developments.


On Tuesday, March 13, 2012 5:25:47 PM UTC-7, Jens wrote:

The exception you see is thrown in RemoteServiceProxy.doInvoke(...) and simply wraps a possible RequestException. These RequestExceptions can be thrown by RequestBuilder.doSend(..) and are wrappers for JavaScriptExceptions that can be thrown by the browser if it can not do an ajax request using XMLHttpRequest.

All these exceptions are chained together so you should log the whole stack trace to get some more information.

That is probably a good next step: I changed it so that now it shows a stack trace of nonsense -- I could
put the symbol table into the app (with SourceMaps?), and then ask users who experience
the problem to email me the stack trace.
 
I don't think its an issue in GWT-RPC. Its just that your customer's browser sometimes can't establish a connection to your server

I still have not been able to see the problem for myself. On the theory that it
is likely to happen in places with weak internet, I have carried my laptop around
to various cafes etc. and run a bunch of apps, but so far no problem.

I have tried a few adventuresome things, like
* in the RemoteServiceServlet I made doGetSerializationPolicy()
always return null, thereby forcing it to use a 1.3.3 compatible policy.
This seems to have helped, in the sense that users had earlier reported
errors related to getting a serialization policy, and since this change,
no one has reported those errors.

Then last Thursday, my associate was giving a training in Sacramento in
a situation with possibly weak internet, at the same time
that several other users were keeping our server engaged with
massive uploads (I am still not sure if server load has anything to do with this).
The trainees were supposed to use our GWT apps. Many of them
got a ...client.rpc.StatusCodeException: 0 whenever the app they were
using tried to read or write through RPC.

The apps seem to report StatusCodeException 0 when they are not able
to reach the server, because I was not able to see any evidence of these
failures in any server log.

My associate says he ended up apologizing to the trainees instead
of covering the material, He thinks we should be investigating something
beside GWT, or at least hiring someone who really knows GWT RPC to
audit our apps. (Is there such a person?)

Another thing I have tried after Thursday was to put some of the critical
RPC calls (logging in) inside an iteration with DeferredCommands and Timers,
so that if the first attempt doesn't work, it will try a few more times before
giving up. I am not yet sure if this makes any difference. These are
desperate (read silly) measures.

Reply all
Reply to author
Forward
0 new messages