Vaadin 7 (7.1.11) Unable to parse RPC call from the client

Hello,
I have a working application that fails to handle RPCs when invoked from
a mobile device.
The application
runs nicely when accessed from a desktop
(Chrome,Firefox and IE 9)

The error shows as follows:

SEVERE:
java.lang.RuntimeException: org.json.JSONException: A JSONArray text must start with ‘[’ at character 1
at com.vaadin.server.communication.ServerRpcHandler.handleBurst(ServerRpcHandler.java:241)

I will check if it has been fixed on 7.1.12 on Monday. Has someone else faced the same problem before?

Would Touchkit resolve this problem? Am I forced to use Touchkit to be able to use Vaadin-based applications from mobile devices?

Thanks in advance:
Ramon Talavera

Stacktrace follows:
Unable to parse RPC call from the client: A JSONArray text must start with ‘[’ at character 1

om.vaadin.server.communication.ServerRpcHandler handleBurst
WARNING: Unable to parse RPC call from the client: A JSONArray text must start with ‘[’ at character 1
com.vaadin.server.DefaultErrorHandler doDefault
SEVERE:
java.lang.RuntimeException: org.json.JSONException: A JSONArray text must start with ‘[’ at character 1
at com.vaadin.server.communication.ServerRpcHandler.handleBurst(ServerRpcHandler.java:241)
at com.vaadin.server.communication.ServerRpcHandler.handleRpc(ServerRpcHandler.java:111)
at com.vaadin.server.communication.UidlRequestHandler.synchronizedHandleRequest(UidlRequestHandler.java:91)
at com.vaadin.server.SynchronizedRequestHandler.handleRequest(SynchronizedRequestHandler.java:37)
at com.vaadin.server.VaadinService.handleRequest(VaadinService.java:1382)
at com.vaadin.server.VaadinServlet.service(VaadinServlet.java:238)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:727)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:303)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)
at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:220)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:122)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:501)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:170)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:98)
at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:950)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:116)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:408)
at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1040)
at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:607)
at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:315)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:722)

Looks as if it is related to Mobile builds of Chrome.
It is working nicely on Firefox for Android.
Not doing anything extrange at all, just a form with two texfields, as soon as one of them tries to synch with the server side an ‘org.json.JSONException: A JSONArray text must start with ‘[’ at character 1’ exception is launched.

On com.vaadin.server.communication.ServerRpcHandler line 131:

[i]
private void handleBurst(UI uI, String burst) {
// TODO PUSH Refactor so that this is not needed
LegacyCommunicationManager manager = uI.getSession()
.getCommunicationManager();

    try {
        Set<Connector> enabledConnectors = new HashSet<Connector>();

        List<MethodInvocation> invocations = parseInvocations(
                uI.getConnectorTracker(), burst); [b]

← expecting a JSON String, but “591299753]” was received instead from Chrome…
[/b]
[/i]

burst is receiving : “591299753]”, I suspect being ‘591299753’ an Id. Maybe it would be easily fixed just
by adding:
if (!burst.startsWith(‘[’) { burst=‘[’+burst; }

or maybe not, I am just figuring it out as I am working with precompiled Vaadin libs.

Hasn’t anybody faced this affair before?

Sounds like Chrome mobile sends something completely different to the server than it should. The RPC call should start with something like "[["0",
where “0” is the target connector id. Can you reproduce the problem with e.g.
http://test.vaadin.com/7.1.11/run/LabelModes?restartApplication
by clicking on some checkbox?

Hello Sir,
exactly the same behaviour as (should not be) expected. I am sending a screen capture of my mobile screen. Big and red ‘Internal error’ message is shown. Directly connected through HSPA using my data carrier, so no proxies present. I am obtaining the same error when directly connected from my mobile to my server being both in the same LAN.

Chrome and Samsung’s web browser (I think it is based on Chromium too) produce the same error. Firefox seems to be running nicely. Unluckily, Vaadin 7.1.12 did not solve the problem.

Thanks for your quick reply.
13514.png

If you set a breakpoint on the server in ServerRpcHandler.handleRpc you should see the full message the client sends in the “changes” variable. It might give some clue to what is going on. The other option would be to add “?debug” to the URL and try to find some hint in the debug window.

Thank you Arthur, I will check it again on Monday as I cannot stay here any longer. This most probably is happening to lots of people when accessing Vaadin based sites from mobile devices making them totally useless, I will try to find the reason from here and post it. It is not only my mobile that did not work, the problem was detected when trying to access the application from a
Samsung Galaxy Tab
tablet and from a
Google Nexus 5
.
Have a nice weekend.

Good morning,
Running the application in debug mode works as a charm. The problem arises when running it in production mode. Once my application is deployed in production mode, it automatically compiles sass. Somehow that does create something that causes Chrome for Android not to be able to communicate with Vaadin applications. Furthermore, the altered css are cached, so for then on, all Vaadin applications (including http://test.vaadin.com/7.1.11/run/LabelModes?restartApplication) stop working in that browser. The solution was:

  1. Clear Chrome’s browser cache
  2. Run my application in debug mode
  3. Access the application so the necessary elements are cached.
  4. Deploy again in production mode.

This makes external Vaadin pages to also work. Not a mess to fix, but have in mind that this could make a browser to stop communicating with Vaadin applications just by accessing a server with the ‘dirty’ files marked as newer so the cached ones are refreshed, for then on you will have a user uncapable of using Vaadin from that Chrome for Android.

I have got a exploit for Vaadin right here in front of me, are you open to negotiation? :slight_smile:

Hi,

I’m experiencing the exact same problem. I just updated Vaadin to 7.1.13 and the problem is still there.

FIY somebody created a defect
here for this issue
.

Thank you. Is your implementation made in a way that it compiles SASS into CSS by using Vaadin’s classes? Mine does so and I am suspicious about it… or maybe it has nothing to do with that.

I occasionaly see the same problem here on Vaadin 7.1.13 when browsing using Chrome from a nexus 7. I don’t use SASS here. Clearing the browser cache seems to fix the problem until the next time it happens.

I did a little more research, an to me it’s not related to the SASS compiler or the browser cache. It looks like this error disappear when I set the Vaadin PushMode to STREAMING instead of using WebSockets.

I’m gonna update the defect with this information.

It was due to a defect in Chrome for Android, seems to be fixed now.