@Petrus: Is there any method to override or listener to use with which you can handle every/close to every request from the application? The service method was just the first method i found which in my test at least was called when using heartbeat and a button. I know that in Vaadin 6 the Transaction listener did sort of that but it’s deprecated now, I think.
Here is another usecase for sessions not expiring when using push: My application runs on several tablets and its main use is to display some information about meeting rooms. There is no user interaction involved so session expiration would be really bad for me.
I know. Also i can use the hearbeat without closeIdleSessions and set the interval to something smaller then the session timeout to keep it alive. This way it would still invalidate the session when the browser window/tab is closed.
This appears to be feature of Atmosphere. It disables the session timeout when the push connection is opened.
Therefore this Vaadin method always returns -1 causing sessions not to expire when push is enabled:
private int getUidlRequestTimeout(VaadinSession session) {
return getDeploymentConfiguration().isCloseIdleSessions() ? session.getSession().getMaxInactiveInterval() : -1;
}
This ticket is related to the issue:
http://dev.vaadin.com/ticket/11514
I just observed something weird:
I deployed my push-app to a local tomcat 7 with session-timeout=3 minutes and closeidlesession=true (heartbeat = 10s although irrelevant)
Then after the app ran for 3 minutes while only the background thread updated a label every minute the session timed out.
I couldn’t observe this behavior when i launched the app in eclipse using the “debug-tomcat”.
When i remove closeidlesession the session stays up.
You could try if the same applies for your app or if that’s just a “problem” on my end.
That seems to be true! The sessions are expired when the application is deployed to standalone Tomcat but not when running Tomcat from Eclipse (debug or no debug). From Eclipse I got it working only by setting init parameter
org.atmosphere.cpr.sessionSupport to
false .
I have a similar issue on JBOSS 7.2 maybe occurs also on others application server.
I tried to add a SessionDestroyListener but it doesn’t work if I have push enabled (it is never fired after close the browser, wait timeout setted to 1 minute and wait 3 * heartbeatInterval setted to 10sec).
If I try to close manually the session then the SessionDestroyListener is fired TWO times for the same session.
The same code with push disabled works fine, the SessionDestroyListener is fired.
Now I’m using pollingIntervall method to avoid the problem
I am experiencing the same issue, and I have NOT enabled push. All the doc I have read discusses the steps necessary to enable push, so I am assuming since I have done none of them, that push is disabled by default. If that is an incorrect assumption, I hope that someone can correct me.
I am using a small test class that extends UI and another class that implements HttpSessionListener. I have the following web.xml parms set:
After 60 seconds, the session expired message appears, but sessionDestroyed is not called. If I click the message box, the page refreshes, but sessionCreated is not called.
Again, my UI class is NOT annotated with @Push, and my web.xml does NOT contain the pushmode parm. I am running Vaadin 7.1.7 on JBoss 7.1.3.
If anyone can help resolve this, it would be much appreciated!
If you use a CDI addon there is unresolved issue with push and session. If you use Spring, push works almost perfectly with Tomcat 7.0.47. When application is deployed into JBOSS, handling session expiration dosen’t work. So, IMHO there is something wrong with atmosphere ↔ vaadin connector.
I agree with Lukasz. There is something seriously wrong going on. To get past this issue for now, we have set the heartbeatInterval greater than the session timeout. The user will not be informed of a session timeout until they attempt to do some activity in the browser, but at least sessionDestroyed is invoked when it should be.
It looks like Eclipse ( or the Vaadin plugin for it? ) is the problem, as Marius/Mika note above. One of my UIs instantiates a singleton which connects to a mySQL database. The number of database connections should remain constant, but instead grow as old sessions are replaced with new ones. Connections from previous sessions are not dropping. I use a keep-alive in the UI that pings the database every hour so the connection pool won’t drop. But when a session closes, the keep-alive stops, the unused database connectons should drop. But they don’t.
I closed the UI - connections persist. Let the session time out - connections persist. Manually close all sessions - connections persist. Shut down Tomcat - connections persist. Quit Eclipse - all database connections drop.
It appears that Eclipse holds open a session, and a UI instance while it is open. Mika’s reference to Eclipse’s org.atmosphere.cpr.sessionSupport looks like a likely suspect and is probably why we sometimes see this as a push problem. When the webapp is deployed to a Tomcat server where no Eclipse is involved the connections ( = sessions) are established and dropped as expected.
I have similar problem,
NO PUSH, but:
I do not enforce idle session to be closed.
!!! missing 3 heartbeats do not coasing UI DetachListener notification.
heartbeats sent as expected (interval is prope met)
heartbeats seem most of the time to extend session TTL.
I think you’re actually describing the desired situation when not using closeIdleSessions=true. As far as i can remember back when i tested out all combinations of setting, that was how it was supposed to work.
Why do you not use closeIdleSessions? Seems like that is exactly the situation it was made for.
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.