Session immediately expired

I try to run an application war with a simple jetty-runner like this: “java -jar jetty-runner.jar xyz.war”.
The problem I have is that the session is immediately expired. In the devlopment via a maven jetty plugin everything works fine. Below is a sample debug output. I can see that jetty is writing to tmp for its pages and the start page is displaying fine in the client browser but unfortunately right after rendering the Session expired message appears.

Any hints?

196msStarting application ROOT-2521314
205msUsing theme: valo
213msVaadin application servlet version: 8.1.6
234msSetting hearbeat interval to 300sec.
244msJSON parsing took 1.27ms
255msHandling message from server
263ms * Handling resources from server
265ms * Handling type inheritance map from server
268msHandling type mappings from server
275msHandling resource dependencies
286ms * Handling type mappings from server completed: 11 ms
290ms * Loading widgets completed: 12 ms
291ms * Handling meta information
293ms * Creating connectors (if needed)
377ms * Updating connector states
437ms * Handling locales
439ms * Updating connector hierarchy
450ms * Sending hierarchy change events
516ms * Running @DelegateToWidget
520ms * Sending state change events
551ms * Passing UIDL to Vaadin 6 style connectors
552ms * Performing server to client RPC calls
553msServer to client RPC call:[16]
554msServer to client RPC call:[0, [object Object]
,[object Object]
,[object Object]
,[object Object]
,[object Object]
,[object Object]
,[object Object]
,[object Object]
,[object Object]
,[object Object]
,[object Object]
,[object Object]
,[object Object]
,[object Object]
,[object Object]
,[object Object]
571ms* Unregistered 0 connectors
572mshandleUIDLMessage: 279 ms
572msStarting layout phase
573msMeasured 0 non connector elements
586msPass 1 measured 6 elements, fired 0 listeners and did 0 layouts.
592msDid overflow fix for 1 elements
598msPass 2 measured 1 elements, fired 0 listeners and did 0 layouts.
598msNo more changes in pass 3
599msTotal layout phase time: 26ms
600ms * Dumping state changes to the console
600msUIDL: undefined
638msFirst response processed 2526 ms after fetchStart
639ms Processing time was 384ms
640msReferenced paintables: 45
694msEstablishing push connection
707msRPC invocations to be sent to the server:
708ms   141 (class com.vaadin.client.ui.ui.UIConnector) :
709ms      com.vaadin.shared.ui.ui.UIServerRpc.resize([1453, 1275, 1453, 1275]
712msSending xhr message to server: {"csrfToken":"3e617a47-000f-4214-8827-5fb3060c443f","rpc":[["141","com.vaadin.shared.ui.ui.UIServerRpc","resize",[1453,1275,1453,1275]
755msJSON parsing took 0.105ms
757msReceived push (undefined) message: for(;;);[{"changes":{},"resources":{},"locales":{},"meta":{"appError":{"caption":"Session Expired","url":null,"message":"Take note of any unsaved data, and <u>click here</u> or press ESC key to continue.","details":null}},"syncId":-1}]

760msResponse didn't contain a server id. Please verify that the server is up-to-date and that the response data has not been modified in transmission.
762msHandling message from server
765ms * Handling resources from server
769ms * Handling type inheritance map from server
771msHandling type mappings from server
772msHandling resource dependencies
773ms * Handling meta information
774ms * Creating connectors (if needed)
774ms * Updating connector states
775ms * Handling locales
776ms * Updating connector hierarchy
782ms * Running @DelegateToWidget
785ms * Sending state change events
785ms * Passing UIDL to Vaadin 6 style connectors
788ms* Unregistered 0 connectors
788mshandleUIDLMessage: 15 ms
789msStarting layout phase
793msMeasured 0 non connector elements
805msPass 1 measured 1 elements, fired 0 listeners and did 0 layouts.
805msNo more changes in pass 2
806msTotal layout phase time: 16ms
808ms * Dumping state changes to the console
808msUIDL: undefined
820msSetting hearbeat interval to -1sec.
820ms Processing time was 59ms
821msReferenced paintables: 45
824msServer visit took 111.825ms
826msJSON parsing took 0.27ms
828msReceived xhr message: for(;;);[{"syncId": 1, "clientId": 1, "changes" : []
, "state":{}, "types":{}, "hierarchy":{}, "rpc" : , "meta" : {}, "resources" : {}, "timings":[2458, 112]
831msIgnored received message because application has already been stopped

Is your widget set up to date? Maybe you have upgraded vaadin but did no compile the widget set. This has in past caused me similar symptoms: initial page is rendered, but immediate error message from the app. You should be able to see the widget set version from the Vaadin
debugger window
's ‘i’ tab.

I checked the widget set version, it is “only” a hash in the debug info. But I checked it in the source pom to be the most recent version: 2.3.0 from org.vaadin.hezamu. Is there any other widget set version meant?

But I checked the page with an other browser and it turns out this is an issue. With Chromium it is working but not with Firefox 57.0. I am developing in Linux which might be too exotic for Vaadin. :wink:


Developing Vaadin applications on Linux platform should not be the root cause of your problem. I have developed Vaadin apps on Linux for few years and I haven’t seen many defferences compared to developing on OS X or Windows.

Not sure what you mean by only a hash in the debug info, and I’m not familiar with the source pom you are referring to.

What I meant with checking the widget set version from the Vaadin debugger:

Make sure that the Client engine version matches the Server engine version in the
Vaadin debugger console.

Attached is the full version information list.

Difficulties with Linux I mean the client browsers not the developping part.

I ran into a similar problem. I’m running a Vaadin application in embedded jetty and reverse proxying it with either apache or haproxy. I upgraded jetty to 9.4 and got immediate “session expired” when reverse proxying with haproxy, but it worked with apache.

The problem with haproxy and jetty 9.4 goes away if I remove the @Push annotation from the Vaadin application, but I don’t want to do that.

Versions: Vaadin 8.1.5, apache 2.4.25-3+deb9u5, haproxy 1.7.5, jetty 9.4.11.v20180605 and 9.3.24.v20180605.

I suspect that the proxy you are using is failing the websocket connection in a way which Vaadin is unable to recover from and fall back to HTTP long polling. As a quick fix you could try to set the Vaadin push Transport mode to LONG_POLLING manually via @Push(transport = Transport.LONG_POLLING). Propper fix would be to configure the proxy to allow websocket connections between the client and Vaadin application’s /PUSH url.

Yes, Transport.LONG_POLLING works with haproxy and jetty 9.4.

But Transport.WEBSOCKET works if I use haproxy and jetty 9.3. I didn’t change haproxy settings at all. So there must be something that needs to be configured differently with haproxy and jetty 9.4 but I have no clue what would it be.

haproxy config has:

  • mode http
  • option forwardfor
  • reqadd X-Forwarded-Proto:\ https
  • timeout tunnel 1h

After a bit of wiresharking, I found that there was no Connection: Keep-Alive header in the request that went from haproxy to jetty. With apache it was there. I added

reqadd Connection:\ Keep-Alive

to haproxy backend config and now it works.

Blindly adding “Connection: Keep-Alive” in the reverse proxy actually breaks websockets with jetty 9.4. It responds with 400 if there are both “Upgrade” and “Keep-Alive”. In this case Vaadin 8.6.0 automatically reverts to long polling even if push with websocket is explicitly requested.

My mistake seems to have been stuffing the same web app with too much features and eventually something broke push with websocket.

I wrote a minimal proof of concept and it seems to work ok. The idea was to split the project into four parts to isolate any non-vaadin websocket stuff from the vaadin app. (84.5 KB)