Seems like Vaadin 7.1.0 is never expiring sessions when Push (mode = PushMode.MANUAL, transport = Transport.STREAMING) is enabled.
Test configuration:
<context-param>
<param-name>heartbeatInterval</param-name>
<param-value>60</param-value>
</context-param>
<init-param>
<param-name>closeIdleSessions</param-name>
<param-value>true</param-value>
</init-param>
<session-config>
<session-timeout>5</session-timeout>
</session-config>
Setting
closeIdleSessions to
true should cause sessions to be closed if no other than heartbeat requests are received, but this does not happen. When Push is disabled sessions are closed as expected.
Should I create a ticket for this or are we doing something wrong?
I think one of the purposes of Push is to not let the session invalidate by always holding a permanent connection to the server. This way the session only times out when the client/browser is closed.
I hope that is not the case. In my opinion server push should have no impact on Vaadin application lifecycle (and according to Vaadin documentation it doesn’t) but only the way the UI gets updated (from server side). The session should always have a maximum inactivity time after which it is automatically closed when required, otherwise we’re in trouble users leaving their browsers open.
I made some tests and it seems like that’s actually the case. My test-case:
session-timeout: 1 minute
heartbeat-interval: 5 seconds
closeidlesessions: true
Automatic push(streaming)
Timer that’s executed every 5 minutes to update the ui
The session didn’t timeout even during the 5 minutes when the timer didn’t access the ui.
One idea i had with which you may be able to achieve this is when you implement your own session handling.
If you override the method service in a custom servlet class you can get every request that’s made by the client. (In my case the push response from the thread wasn’t noticeable in the service method but the heartbeat and button click was)
@Override
protected void service(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
System.out.println(request.getPathInfo()); // prints e.g.: "/HEARTBEAT/" for the heartbeat and "/PUSH/"
// for a button click but nothing for the pushing in the background thread.
super.service(request, response);
}
I never used something like this myself but maybe it can be useful in your case.
Overriding the service method on the servlet will not work, 99% sure the websocket is not serviced via the service method.
You should probably run a thread that keeps tab on session activity and close the session if you need to ( I would advise you to at least notify the UIs for that session that your are going to close them before you do so ).
I think one of the reasons you don’t want the session to timeout like normally is for example a stock ticker, or any type of monitoring application ( where you want to push events ) , you will not likely have any activity on the application from the browsers side.
@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.