WARNING: Server message without client id received

Vaadin 6 / 7 / 8
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
21

Gerko,

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

  • John
22

John,

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

Gerko

23

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