RPC problem: what about Issue 368 ?

[stuckagain]

Hi,

I know everybody is hard at work on GWT 1.5, keep it up! ;-)

Will there be a fix for issue 368 ? Its about RPC that sometimes fails
on the first request.
I get stacktraces like these, and apparently I am not the only one
that ran into it. It's not really the best way to make a first
impression:

java.lang.IndexOutOfBoundsException: Index: 12, Size: 12
at java.util.ArrayList.RangeCheck(ArrayList.java:546)
at java.util.ArrayList.get(ArrayList.java:321)
at
com.google.gwt.user.server.rpc.impl.ServerSerializationStreamReader.extract(ServerSerializationStreamReader.java:
282)
at
com.google.gwt.user.server.rpc.impl.ServerSerializationStreamReader.deserializeStringTable(ServerSerializationStreamReader.java:
228)
at
com.google.gwt.user.server.rpc.impl.ServerSerializationStreamReader.prepareToRead(ServerSerializationStreamReader.java:
101)
at com.google.gwt.user.server.rpc.RPC.decodeRequest(RPC.java:234)
at
com.google.gwt.user.server.rpc.RemoteServiceServlet.processCall(RemoteServiceServlet.java:
264)
at
com.google.gwt.user.server.rpc.RemoteServiceServlet.doPost(RemoteServiceServlet.java:
187)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:763)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:856)
at com.evermind[Oracle Containers for J2EE 10g
(10.1.3.3.0) ].server.http.ServletRequestDispatcher.invoke(ServletRequestDispatcher.java:
713)
at com.evermind[Oracle Containers for J2EE 10g
(10.1.3.3.0) ].server.http.ServletRequestDispatcher.forwardInternal(ServletRequestDispatcher.java:
370)
at com.evermind[Oracle Containers for J2EE 10g
(10.1.3.3.0) ].server.http.ServletRequestDispatcher.unprivileged_forward(ServletRequestDispatcher.java:
259)
at com.evermind[Oracle Containers for J2EE 10g
(10.1.3.3.0) ].server.http.ServletRequestDispatcher.access
$100(ServletRequestDispatcher.java:51)
at com.evermind[Oracle Containers for J2EE 10g
(10.1.3.3.0) ].server.http.ServletRequestDispatcher
$2.oc4jRun(ServletRequestDispatcher.java:193)
at oracle.oc4j.security.OC4JSecurity.doPrivileged(OC4JSecurity.java:
283)
at com.evermind[Oracle Containers for J2EE 10g
(10.1.3.3.0) ].server.http.ServletRequestDispatcher.forward(ServletRequestDispatcher.java:
198)
at
com.swift.gwt.platform.server.DispatchServlet.dispatch(DispatchServlet.java:
75)
at
com.swift.gwt.platform.server.DispatchServlet.doPost(DispatchServlet.java:
21)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:763)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:856)
at com.evermind[Oracle Containers for J2EE 10g
(10.1.3.3.0) ].server.http.ResourceFilterChain.doFilter(ResourceFilterChain.java:
65)
at
com.swift.gwt.j2ee.server.GwtCacheFilter.doFilter(GwtCacheFilter.java:
51)
at
com.swift.gwt.j2ee.server.GwtCacheFilter.doFilter(GwtCacheFilter.java:
36)
at com.evermind[Oracle Containers for J2EE 10g
(10.1.3.3.0) ].server.http.ServletRequestDispatcher.invoke(ServletRequestDispatcher.java:
623)
at com.evermind[Oracle Containers for J2EE 10g
(10.1.3.3.0) ].server.http.ServletRequestDispatcher.forwardInternal(ServletRequestDispatcher.java:
370)
at com.evermind[Oracle Containers for J2EE 10g
(10.1.3.3.0) ].server.http.HttpRequestHandler.doProcessRequest(HttpRequestHandler.java:
871)
at com.evermind[Oracle Containers for J2EE 10g
(10.1.3.3.0) ].server.http.HttpRequestHandler.processRequest(HttpRequestHandler.java:
453)
at com.evermind[Oracle Containers for J2EE 10g
(10.1.3.3.0) ].server.http.HttpRequestHandler.serveOneRequest(HttpRequestHandler.java:
221)
at com.evermind[Oracle Containers for J2EE 10g
(10.1.3.3.0) ].server.http.HttpRequestHandler.run(HttpRequestHandler.java:
122)
at com.evermind[Oracle Containers for J2EE 10g
(10.1.3.3.0) ].server.http.HttpRequestHandler.run(HttpRequestHandler.java:
111)
at oracle.oc4j.network.ServerSocketReadHandler
$SafeRunnable.run(ServerSocketReadHandler.java:260)
at com.evermind[Oracle Containers for J2EE 10g
(10.1.3.3.0) ].util.ReleasableResourcePooledExecutor
$MyWorker.run(ReleasableResourcePooledExecutor.java:303)
at java.lang.Thread.run(Thread.java:595)

[Miguel Méndez]

It sounds really strange that it fails on the first request and then succeeds on subsequent ones.  The RPC proxy is stateless the only reason for a difference between the first request and a subsequent one could only come from a difference in the payload data.  Is the data the same in the success and failure cases?

We'll need a repro case to really move this forward.

--
Miguel

[David]

Hello Miguel,

Well, this happens sometimes in my application, but after a server
restart it happens more often.
This happens on IE6 , using a SSL connection (don't know if that is
relevant, but IE6 sucks when it comes to SSL).

The request is twice the same, I'm just calling a method with this signature:
public void login(String pContextId, Long pGroupId, Long pInstance,
String pUsername, String pPassword, AsyncCallback pCallback);

The problem is that I sometimes have this with other RPC calls
intiated by a timer. In my case if this timer is checking the state of
the user on the server and if that fails we assume that the server has
logged out the user and we move back to the login screen.

I'll see if I can create a simple repro case, but it might just be a
result of a IE6 bug somehow ? Multiple people have reported similar
stacktraces and I have investigated my code (I try to assume that
every bug is mine), but I don't see anything wrong, except for the
request failing on the server side... I'll try and debug on the server
side to see what the payload is when it crashes, maybe that could give
a hint.

David.

[David]

Miguel,

I managed to get it reproduced while using a debugger on the application server.
I noticed that the encodedToken variable holds something that ends with:
encodedTokens:
[239]= ? [\\uffff]
[240]= d [\\u0064]
[241]= e [\\u0065]
[242]= m [\\u006d]
[243]= o [\\u006f]
[244]= ? [\\uffff]
[245]= \f [\\u000c]
[246]= 0 [\\u0030]
[247]= 9 [\\u0039]
[248]= [\\u000e]

But the tokenList stops right after the entry "demo":
[3, 0, 10, https://behw1348.swift.corp/swp/group/browse/,
4FAB7CBBD3A32A92C0873AF4B274547A,
com.swift.gwt.login.client.service.GroupLoginService, login,
java.lang.String, java.lang.Long,
644416ba-e0a3-47d6-bc8a-964f9ee6a40b, java.lang.Long/4227064769, demo]

So indeed the out of bounds happens because the code is expecting a 10th field.

Could it be a coincidence that the last field, missing from the
request is an obfuscated password ? Could it be that not all
characters are correctly transported ? The obfuscation is different on
every request so that explains why it does not happen always.

Is this a bug in my code ?

David