WARNING: Server message without client id received

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?

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?

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>

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.

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">

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?

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

John Kroubalkian: 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?

 

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>

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

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

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;
            }

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.

Hi Steve,

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

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

- John

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...

Steve,

We are using autmatic push:

@Push(value=PushMode.AUTOMATIC,transport=Transport.WEBSOCKET)

Thanks for having a look.

- John

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...

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

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. 

Steve,

The project in question is not using an optimized widgetset.

- John

Gerko,

Did you encounter a situation where your deployed application seemed to bundle both the 7.5.10 and 7.6.0 libraries?

- John

John,

The default ivy libs were 7.6.0, but the widgetset-compile and the ivy nodeploy jars were 7.5.9.

Gerko

Gerko,

The multi-module maven project has been cleaned.  The libraries all appear to be 7.6.0.

Here are the vaadin-specific libraries.   Does anyone spot a conflict?

[INFO] --- maven-dependency-plugin:2.8:list (default-cli) @ venn-frontend-vaadin-poc ---
[INFO]    com.vaadin:vaadin-testbench-api:jar:7.4.8:test
[INFO]    com.vaadin:vaadin-client-compiler-deps:jar:1.2.0:provided
[INFO]    com.vaadin:vaadin-testbench-core:jar:4.0.3:test
[INFO]    com.vaadin:vaadin-push:jar:7.6.0:compile
[INFO]    com.vaadin.external.atmosphere:atmosphere-runtime:jar:2.2.7.vaadin1:compile
[INFO]    com.vaadin:vaadin-server:jar:7.6.0:compile
[INFO]    com.vaadin:vaadin-themes:jar:7.6.0:compile
[INFO]    com.vaadin:vaadin-sass-compiler:jar:0.9.13:compile
[INFO]    com.vaadin:vaadin-client-compiler:jar:7.6.0:provided
[INFO]    com.vaadin:vaadin-client:jar:7.6.0:provided
[INFO]    com.vaadin.external.flute:flute:jar:1.3.0.gg2:compile
[INFO]    com.vaadin:vaadin-testbench:jar:4.0.3:test
[INFO]    com.vaadin.addon:vaadin-charts:jar:2.1.3:compile
[INFO]    com.vaadin.external.streamhtmlparser:streamhtmlparser-jsilver:jar:0.0.10.vaadin1:compile
[INFO]    org.vaadin.addon:confirmdialog:jar:2.1.3:compile
[INFO]    com.vaadin.external.google:guava:jar:16.0.1.vaadin1:compile
[INFO]    com.vaadin.external.slf4j:vaadin-slf4j-jdk14:jar:1.6.1:compile
[INFO]    com.vaadin:vaadin-shared:jar:7.6.0:compile

Thanks in advance,

- John
 

Check what the info tab in the ?debug window says, that will tell you what is really in use

Shows 7.5.8?  

As I suspected, you need to fix that :) Recompile your widget set using 7.6.0

Hmmm...even after running the following maven goals (see below) - still showing 7.5.8 in ?debug:

• vaadin:update-widgetset
• vaadin:compile

Try 

mvn vaadin:compile -Dgwt.compiler.force=true

Otherwise, remove the widget set first (mvn clean vaadin:clean) and ensure the app does not start. Then run vaadin:compile again

Hello Artur,

I have attempted the recommended operations but still see "Client engine version 7.5.8" in the debug window.

mvn clean
mvn clean vaadin:clean vaadin:compile 
mvn clean vaadin:clean vaadin:compile  -Dgwt.compiler.force=true
​
Any suggestions?

Even after manually clearing Widgetset directories can see "var $gwt_version = \"7.5.8\"" in:

53CD41F41F6D8C3C83FB4A808EFD8C1A.cache.js
com.jgk.venn.frontend.vaadin.poc.PocWidgetSet.devmode.js

How is the $gwt_version set?

\

ok 7.6.0 up and running on the client :-)

John Kroubalkian: \

ok 7.6.0 up and running on the client :-)

John, 
What was the magic incantation to finally get the client to show 7.6.0?
Thanks!

EDIT: mvn vaadin:compile -Dgwt.compiler.force=true worked for me the first time.

Andrew,

For some reason when compiling the widget set (vaadin:compile) the old version [7.5.8] was sticking.

I went into each module (a multi-module maven project) and manually removed the widgetset directory and then rebuilt the widgetset.

- John