Important Notice - Forums is archived
To simplify things and help our users to be more productive, we have archived the current forum and focus our efforts on helping developers on Stack Overflow. You can post new questions on Stack Overflow or join our Discord channel.

Vaadin lets you build secure, UX-first PWAs entirely in Java.
Free ebook & tutorial.
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>
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
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
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?
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