Is there a way to programmatically set closeIdleSessions to true/false?
Basically I need to implement a “Keep me logged in” option when the user logs in. It seems the best way is to set the closeIdleSessions property of the session to false but I can’t find a way to set this during session initialization.
One possible way is to override the VaadinServlet.createDeploymentConfiguration() method and use my own class which extends DefaultDeploymentConfiguration and use it to replace the config during sessionInit(). But this seems like too much for such a simple thing. Is that the right way to do it?
There are multiple issues here. The problem we have is that the session timeout has to be customer configurable and the heartbeat must be adjusted accordingly. But the heartbeat can’t be changed programmatically. We’ve tried everything, including replacing the Service, Servlet and DeploymentConfiguration. You have to do all of those just to get the heartbeat value where it needs to go when not using the annotation. However, even though we can see that heartbeats are happening, via Firebug, the session times out anyway.
We are deploying to Tomcat 7 (Eclipse server and stand-alone). We are using the NIO / WebSockets support and Push mode is automatic. Java 7 and 8. Tried CloseIdleSessions true and false. Firefox, Chrome and IE. Vaadin 7.3.2.
Sessions time out no matter what, even with heartbeats being sent. Part of the problem is the Servlet Spec. Session timeout is too simplitic a solution. Interacting with the Vaadin components in the UI does not send service requests, which is what resets the session “timer”. The heartbeat is supposed to reset the timer. We’ve looked at that code and its sending a dummy page request and then intercepting the response and throwing it away so the browser stays on the same page. Interesting solution if it worked. It only works when using the annotation.
The heartbeat needs to be dynamically configurable. Our only alternative is to stop using the annotations and use web.xml for everything.
The answer is complicated. First you need to understand that page requests happen via a servlet request and that is the only thing that will reset the session timer (why I don’t like the Servlet Spec.). The heartbeat sends a page request and resets the timer, although we were unable to change the heartbeat programmatically. The heatbeat needs to happen at least once before the session timeout (better to have 3 heartbeats because that’s the default “missed hartbeats” test). You don’t want too many heartbeats with Push enabled because there is a potential “hang” problem and too many heartbeats seems to contribute to it. The hang happens randomly.
Vaadin’s browser side components use “connectors” to talk to the server, via WebSockets, which does not reset the session timer, and the implementation has issues. Tomcat 7 and Push does not work reliably, partly for this reason, not necessarily Vaadin’s fault.
We have recently moved to the latest Vaadin 7.3.x and Tomcat 8, to fix some things related to Vaadin hanging, and you might give that a try. But we also abandoned trying to set the session timeout and heartbeat programmatically. We haven’t given up completely yet. When priorities allow we will try again with the new Vaadin, Atmosphere and Tomcat.
We had to give up on Push completely due to our customers using virtual machine environments and Push hangs often when used in a VM. The complexity stems from the fact that you have Vaadin built on top of Atmosphere running inside Tomcat’s servlet implementation, and there are verified bugs in all 3. The Tomcat and Atmosphere developers have been trying to fix the ones we’ve identified, with some success. Some problems remain, however. Not sure what the Vaadin team is working on. We switched to “short polling” to get around the hang problem and that seems to be working 99.9% of the time.
I will look at our configuration and post it here. That might help.
This is still a vexing issue with websockets and sessions timing out.
Is there a bug with the HEARTBEAT requests? Are they going over HTTP as expected? Our session timeout is 30 minutes or 60 minutes, but we seem to fail sooner than that, and we often fail while the user is busy working the UI, and that’s not good.
We can see lots of heartbeat requests in the Tomcat access log, so it seems like they work at least sometimes.