WARNING: Server message without client id received

Vaadin 6 / 7 / 8
1

I’m testing vaadin 7.6 alpha 1 and I’m getting large number of the following log messages:

Dec 04, 2015 7:01:50 AM com.vaadin.server.communication.ServerRpcHandler$RpcRequest <init>
WARNING: Server message without client id received

In the chrome console I’m seeing the following logs which seem to correlate.

Fri Dec 04 07:01:52 GMT+1100 2015 com.vaadin.client.ApplicationConnection INFO: * Passing UIDL to Vaadin 6 style connectors au.org.scoutmaster.AppWidgetSet-0.js:2894 Fri Dec 04 07:01:52 GMT+1100 2015 com.vaadin.client.ApplicationConnection INFO: * Performing server to client RPC calls au.org.scoutmaster.AppWidgetSet-0.js:2894 Fri Dec 04 07:01:52 GMT+1100 2015 com.vaadin.client.ApplicationConnection INFO: * Unregistered 0 connectors If I put a break point in the above class I see it processing a message:
{“csrfToken”:“4c5c6a88-7eb1-4deb-9f71-8f83fc968cd8”,“rpc”:[[“0”,“com.vaadin.shared.ui.ui.UIServerRpc”,“poll”,
]],“syncId”:293}

I’ve enabled push via:

@Push On my NavigatorUI

And my web.xml contains:

    <servlet>
        <servlet-name>Scoutmaster Private Application Servlet</servlet-name>
        <servlet-class>com.vaadin.server.VaadinServlet</servlet-class>
        <init-param>
            <description>Scoutmaster Private UI</description>
            <param-name>UI</param-name>
            <param-value>au.org.scoutmaster.application.NavigatorUI</param-value>
        </init-param>
        <init-param>
            <param-name>org.atmosphere.cpr.AtmosphereInterceptor</param-name>
            <!-- comma-separated list of fully-qualified class names -->
            <param-value>au.com.vaadinutils.servlet.AtmosphereFilter
            </param-value>
        </init-param>

        <init-param>
            <param-name>pushmode</param-name>
            <param-value>automatic</param-value>
        </init-param>
        <async-supported>true</async-supported>
    </servlet>

Interestingly when I first start my app the messages aren’t displayed until I resize the browser window. They then run whilst the resize occurs.

When I go to a particular page on my site the error starts being logged continously even after I leave that page.

Any ideas how I can stop this message being generated?

2

Hi Brett,

First off, could you update to 7.6 beta1 or the latest nightly (beta2 should also be available tomorrow!) and see if you still get the messages?

3

Sorry, my mistake I meant to say that I’m running beta 1 not alpha 1

From my pom.xml

    <vaadin.version>7.6.0.beta1</vaadin.version>
4

I’m having the same issue with <vaadin.version>7.6.0</vaadin.version>.

I’m running my Vaadin applications on Tomcat 8.0.18.

Any solution to this issue? It looks like the clientId is a new feature in 7.6 but isn’t being populated in the RpcRequest causing the warning.

5

I think I might have solved my issue by updating my web.xml to use web-app version 3.1.

<web-app 
    version="3.1" 
    metadata-complete="false"  
    xmlns="http://xmlns.jcp.org/xml/ns/javaee" 
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
    xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd">
6

After upgrading to Vaadin 7.6.0, we are getting the same message:

[color=#FF0000] Jan 07, 2016 7:43:20 AM com.vaadin.server.communication.ServerRpcHandler$RpcRequest <init> WARNING: Server message without client id received [/color] NOTE: running in
Tomcat 8.0.30
 [apache-tomcat-8.0.30]

Rob W:
We do not use a web.xml in our project.
Q: Do you, or anyone else, know how to specify

version=“3.1”

 via a servlet annotation?

7

Same problem, do you have any solution?
I updated the vaadin to 7.6.0 today and then this message never stopped.

8

I’m not aware of a servlet annotation for the version. From what I read 3.1 should be the default for Java7EE and Tomcat 8.

Another thing to look for is to make sure your war file isn’t deploying the javax.servlet-api-*.jar

You could also try adding a simple web.xml and see if that fixes your problem (This should still see your servlets that have the annotations): <web-app version="3.1" metadata-complete="false" xmlns="http://xmlns.jcp.org/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd"> </web-app>

9

Just a sanity check, you did check the debug window that the widget set and servlet versions match and say 7.6.0? If so, in what case do you see the warning message? It should not have anything at all to do with servlet 3.0 vs 3.1

10

Hello Artur, I’ve moved back to 7.5.10 pending resolution on
11995580
.

As soon as I get a chance I’ll promote to 7.6.0 and try to further isolate the scenario.

Thank you,

John

11

Hello Artur and Matti,

These two (issues
11725516
 and
11995580
) may be related. Could PUSH be the problem?

I wrote a small Vaadin app to isolate the toggling scenario described in
11995580
. It worked fine under 7.6.0.

However, the application where it does not work, there is PUSH enabled and I get the following two messages with 7.6.0:

Jan 08, 2016 11:50:45 AM com.vaadin.server.communication.ServerRpcHandler$RpcRequest <init>
WARNING: Server message without client id received

So, Matti, where you click your toggle button there is no corresponding WARNING message. But in our PUSH application, there is such a message.

Thanks,

John

12

In class
ServerRpcHandler.RpcRequest
 :

    if (json.hasKey(ApplicationConstants.CLIENT_TO_SERVER_ID)) {
                clientToServerMessageId = (int) json
                        .getNumber(ApplicationConstants.CLIENT_TO_SERVER_ID);
            } else {
                getLogger()
                        .warning("Server message without client id received");
                clientToServerMessageId = -1;
            }
13

John, I had been receiving those messges and like you, traced the source to that block of code. I lack detailed insight, but the messages, now gone, seemed to be generated when I restricted the threads generated by a Tomcat connector. I had been interested in reducing the seemingly excessive number of threads/connectors used by Tomcat (8.0.30) and wondered if I could reduce thread management overhead by adjusting the maxConnections, maxThreads, minSpareThreads, connectonTimeout and acceptCount attributes. Well yes, the tweaking provided the inteneded thread/connector count reductions, but generated your messages as a side effect. Could it be that connections were terminated then respawned with the same connector number, but those new connections didn’t recognize the references in the client heartbeats? Dunno. But allowing the Tomcat’s default connector settings eliminated the Vaadin errors. I tried using APR, NIO and NIO2 connectors - didn’t seem to matter.

14

Hi Steve,

Thanks for the feedback. We are currently using the Tomcat defaults.

On your project were you using PUSH (vaadin-push)?

  • John
15

Yes, manual push with Websocket, Java 8 (latest), Tomcat 8.0.30, Vaadin 7.6.0. If I get a chance I will try re-create the problem - it may have been on a touchkit UI…

16

Steve,

We are using autmatic push:

@Push(value=PushMode.AUTOMATIC,transport=Transport.WEBSOCKET) Thanks for having a look.

  • John
17

I tried for an hour to reproduce the problem using a variety of Tomcat connector variations. Unable. John - do you use an optimized widgetset? If so, you might check the debug window for the 7.6 version of the eagerConnectors list. I made some changes to lists (standard and mobile) following the upgrade to Vaadin 7.6. Maybe that’s what eliminated the errors…

18

If anybody has an example project where this happens, I would be happy to take a look. I’m having a hard time seeing when this would happen (maybe I missed something obvious) because RPC from the client to the server do

payload.put(ApplicationConstants.SERVER_SYNC_ID, getMessageHandler() .getLastSeenServerSyncId()); payload.put(ApplicationConstants.CLIENT_TO_SERVER_ID, clientToServerMessageId++); In the example JSON I see in this thread, the SERVER_SYNC_ID (“syncId”) has been set but CLIENT_TO_SERVER_ID (“clientId”) has not been set. This should obviously not happen, unless you have an old widget set, as 7.5 only adds “syncId” and “clientId” is a new feature in 7.6

19

I had the problem too, also with push. The problem was that the widgetset-compile libraries weren’t updated to 7.6.0 in Eclipse. After resolving the jars again and recompiling the widgetset, the problem was solved.

20

Steve,

The project in question is not using an optimized widgetset.

  • John