encodedRequest cannot be empty

[Jason Brome]

Hi,

We've been recently experiencing a series of the 'encodeRequest'
exceptions in our environment. I have included a typical stack trace
below. The majority of RPC requests from browsers are getting
through without issue, but we do see these from time-to-time, with
corresponding 'Call failed on server; see server log for details'
errors in the browser.

Has any experienced this issue, and, if so, do you have any
suggestions on how to track down what could be causing these request
appear as an empty payload?

Environment:

- GWT 1.5.3
- Apache Tomcat 6.0.18
- Spring Framework 2.5.2
- Fronted with Apache 2.2.3 using mod_proxy_ajp
- RHEL 5.2

Thanks,

Jason

Exception Stack Trace:

Jan 13, 2009 11:40:37 AM org.apache.catalina.core.ApplicationContext
log
SEVERE: Exception while dispatching incoming RPC call
java.lang.IllegalArgumentException: encodedRequest cannot be empty
at com.google.gwt.user.server.rpc.RPC.decodeRequest(RPC.java:226)
at com.google.gwt.user.server.rpc.RPC.decodeRequest(RPC.java:164)
at com.xxx.yyy.server.services.ZzzServerServlet.processCall
(ZzzServerServlet.java:42)
at com.google.gwt.user.server.rpc.RemoteServiceServlet.doPost
(RemoteServiceServlet.java:86)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:637)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
at
com.xxx.yyy.server.util.ServletWrappingController.handleRequestInternal
(ServletWrappingController.java:58)
at
org.springframework.web.servlet.mvc.AbstractController.handleRequest
(AbstractController.java:153)
at
org.springframework.web.servlet.mvc.SimpleControllerHandlerAdapter.handle
(SimpleControllerHandlerAdapter.java:48)
at org.springframework.web.servlet.DispatcherServlet.doDispatch
(DispatcherServlet.java:874)
at org.springframework.web.servlet.DispatcherServlet.doService
(DispatcherServlet.java:808)
at org.springframework.web.servlet.FrameworkServlet.processRequest
(FrameworkServlet.java:523)
at org.springframework.web.servlet.FrameworkServlet.doPost
(FrameworkServlet.java:463)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:637)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter
(ApplicationFilterChain.java:290)
at org.apache.catalina.core.ApplicationFilterChain.doFilter
(ApplicationFilterChain.java:206)
at com.capgent.cpt.services.web.CacheFilter.doFilter(CacheFilter.java:
86)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter
(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter
(ApplicationFilterChain.java:206)
at
org.springframework.orm.hibernate3.support.OpenSessionInViewFilter.doFilterInternal
(OpenSessionInViewFilter.java:198)
at org.springframework.web.filter.OncePerRequestFilter.doFilter
(OncePerRequestFilter.java:75)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter
(ApplicationFilterChain.java:235)
at org.apache.catalina.core.ApplicationFilterChain.doFilter
(ApplicationFilterChain.java:206)
at org.apache.catalina.core.StandardWrapperValve.invoke
(StandardWrapperValve.java:233)
at org.apache.catalina.core.StandardContextValve.invoke
(StandardContextValve.java:191)
at org.apache.catalina.core.StandardHostValve.invoke
(StandardHostValve.java:128)
at org.apache.catalina.valves.ErrorReportValve.invoke
(ErrorReportValve.java:102)
at org.apache.catalina.core.StandardEngineValve.invoke
(StandardEngineValve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service
(CoyoteAdapter.java:286)
at org.apache.jk.server.JkCoyoteHandler.invoke(JkCoyoteHandler.java:
190)
at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:
283)
at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:767)
at org.apache.jk.common.ChannelSocket.processConnection
(ChannelSocket.java:697)
at org.apache.jk.common.ChannelSocket$SocketConnection.runIt
(ChannelSocket.java:889)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run
(ThreadPool.java:690)
at java.lang.Thread.run(Thread.java:595)

And the corresponding entry from the Apache log - note that 500 error:

xxx.xxx.xxx.xxx - - [13/Jan/2009:11:40:37 -0500] "POST /somelink/
service/populate HTTP/1.1" 500 57 "http://somereferralurl/
9DA7A48037122BFC2145DEF3E12CA721.cache.html" "Mozilla/4.0 (compatible;
MSIE 7.0; Windows NT 5.2; WOW64; .NET CLR 1.1.4322; .NET CLR
2.0.50727; MS-RTC LM 8; InfoPath.1)"

[todd....@gmail.com]

So you are overriding processCall in you
com.xxx.yyy.server.services.ZzzServerServlet class. Are you doing any
manipulation to the payload that might make it null?

[Jason Brome]

Todd,

Yes - here's a sinppet of what happens in processCall prior to the
invocation of RPC.decodeRequest:

public String processCall(String payload) throws
SerializationException
{
try
{
long starttime = System.currentTimeMillis();
String returnvalue = "";
Response response = new Response();
RPCRequest rpcRequest = RPC.decodeRequest(payload,
this.getClass(), this);
// snip

The issue is that the one or two remote services and specific methods
that failed with this exception are commonly used throughout the
application, so, unfortunately, it is not a consistent failure of
those methods.

Also, looking at where the exception is thrown by the RPC class,
payload is an empty String, rather than a null pointer:

(RPC.java line:225-227)
if (encodedRequest.length() == 0) {
throw new IllegalArgumentException("encodedRequest cannot be
empty");
}

Which means, looking back up through the invocation history, that
RPCServletUtils.readContentAsUtf8 may be returning an empty String.

Jason


On Jan 14, 8:57 am, "todd.sei...@gmail.com" <todd.sei...@gmail.com>
wrote:

[Jason Brome]

Just to follow up on this topic - we enabled mod_logio on our Apache
server to log the size of the incoming requests. Based upon the
initial data points we're getting from that data, it looks like the
body of the POST is not making it to our server. This now suggests
that it may either be some behavior happening with the browser, or
some interim proxy. The frustrating part is that it does not happen
consistently - some requests will come through just fine, others will
come through without the payload.

I will post back with any further updates. Again, if anyone has
experienced a scenario like this, I would love to hear about what you
discovered.

Best,

Jason

[Jason Brome]

I wanted to give everyone an update on this topic. After doing
further analysis, and working with our customer, the cause of the
periodic empty requests was found to be a Microsoft Internet Security
and Acceleration (ISA) server. The ISA server was recently
decommissioned, and since that time we have not experienced this
issue.

Jason

[christophe...@gmail.com]

Old post, I know, but if anyone encounters this, there's more discussion about it here:

https://groups.google.com/forum/#!msg/google-web-toolkit/3sJkTjE4npk/EvPvDBnWwdQJ

From what I've seen, it could either be an NTLM authentication issue, or a problem with IE sending partial requests after a TCP connection reset.

Chris