RPC communication stops functioning when running with Internet Explorer

[PJ]

Hi everybody,
I have problems with an app that strangely stops functioning while
running with IE6 and IE7. The basic scenario is as follows:

1. The app loads and works properly at first

2. After some random time running, the RPC communication stops working
and exceptions are found in the server log: "ServletException: Client
did not send x bytes as expected" (full stack trace below). RPC calls
are sometimes returned after long time (often several minutes) with
the exception "com.google.gwt.user.client.rpc.InvocationException: The
call failed on the server; see server log for details". But mostly the
calls seem to disappear in cyberspace.

3. If the page in this state is refreshed (using shift or not) the
application does not load. But if IE is completely restarted, the
application loads and works for a while and we are back to 1 again.
(How is this possible? It seems the browser gets caught in a corrupt
state?)

I get this problem running the app on a remote test server (Tomcat 5.5
on Linux version 2.6.23.16-grsec), but I cannot reproduce it locally.
And I have never been able to reproduce it at all with Firefox. GWT
version is 1.4.61.

There are some discussions on the "Client did not send x bytes as
expected" exception and the general consensus seem to be that these
are caused by closed browsers (http://groups.google.com/group/Google-
Web-Toolkit/browse_thread/thread/c4924b5c6e3b7413/a0f5d6c8e71a80f8?
lnk=gst&q=servletexception+client+send+bytes+expected+#). This is not
the case here however; this behavior appears when testing with only
two clients and it appears without any of them being closed.

Overriding shouldCompressResponse does not make a difference either
(http://groups.google.com/group/Google-Web-Toolkit/browse_thread/
thread/1d56ad62d9222d15/209c711176622927?
lnk=gst&q=shouldcompressresponse#209c711176622927).

Any help mostly appreciated. Thanks,

/PJ

Full stack trace from Tomcat log (the number of bytes is varying):

javax.servlet.ServletException: Client did not send 511 bytes as
expected
at
com.google.gwt.user.server.rpc.RemoteServiceServlet.readPayloadAsUtf8(RemoteServiceServlet.java:
131)
at
com.google.gwt.user.server.rpc.RemoteServiceServlet.doPost(RemoteServiceServlet.java:
178)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:
710)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:
803)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:
269)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:
188)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:
213)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:
174)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:
127)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:
117)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:
108)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:
174)
at
org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:200)
at
org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:283)
at
org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:773)
at
org.apache.jk.common.ChannelSocket.processConnection(ChannelSocket.java:
703)
at org.apache.jk.common.ChannelSocket
$SocketConnection.runIt(ChannelSocket.java:895)
at org.apache.tomcat.util.threads.ThreadPool
$ControlRunnable.run(ThreadPool.java:689)
at java.lang.Thread.run(Thread.java:595)

[Amit Kasher]

We also experience this issue and have a some findings.

We have a production application for over 8 months at around 4 hits
per second activity. We see this error message every minute or two.
Clients are getting this error when using firefox as well.

We have been working on it for quite a long time, and still no
resolution nor have we even managed to reproduce it ourselves. Things
we tried but in vain: Tried different browsers (firefox as well),
different machines, different TCP registry configurations, tried
stopping/killing browsers during request, tried different geographical
locations of the application servers, tried different ISPs of server/
clients, tried using apache+mod_jk as a frontend http server or just
JBoss, tried returning false in shouldCompressResponse, etc...

2 findings we did have, though didn't lead to any resolution yet, are:

We used tcpdump sniffer in the server to analyze the exact content of
the packets received when this error occurs. An interesting finding
was that the HTTP request body received in the server was either empty
or contained exactly 80% of the expected (correct) length, as
indicated in the content-length HTTP header (and later in the
exception message text).

Also, there are clients/IP addresses that are more prone to experience
this error.

The explanation of aggressively stopped requests/browsers controlled
by the user is not the one in this case, though it was also our first
instinct... We are now considering multiple causes including client's
LAN, some network devices, operating systems, and various other causes
or perhaps conjunction of some.

We would really appreciate any kind of insight for this. We are
willing to cooperate and put our time to investigating this further.

Thanks