Session keep-alive, forever ?

Vaadin 6 / 7 / 8
1

How does Vaadin deal with prolific mobile devices that allow you to run your browser in the background? Take Joe for example who visits my application, then openes another browser window to look at some other website, but then forgets my application is still running in another browser window (in-fact, Joe really never closes his browser windows, like most users on mobile devices, he just opens a new one). Then eventually Joe closes the browser (which isn’t really closed, just pushed to the background) to play the Angy Birds app.

Because Vaadin requires sessions and keep-alives are sent (by default) every 5 minutes, the possibility of a session being kept alive indefinitely is a VERY REAL possibility. Relying on any given device to pause any javascript running on a page in a browser, that’s running in the background, doesn’t really seem safe or smart.

​How does Vaadin solve this dilemma that could possibly have thousands of devices keeping sessions alive or constantly being regenerated, indefinitely?

2

I may have answered my own question, but thoughts are welcome.

I suspect the right answer is simply to disable polling altogether and rely instead on user button clicks (or submits) to keep the session alive. This would also mean extending session times from the deafult of 20 minutes to something like (perhaps) a couple of hours.

3

Read “Session Expiration” on
https://vaadin.com/docs/-/part/framework/application/application-lifecycle.html
 about closeIdleSessions.

4

@Edison

“If the
closeIdleSessions
 parameter of the servlet is set to
true
 in the web.xml, as described in Using a web.xml Deployment Descriptor, the session and all of its UIs are closed when the timeout specified by the session-timeout parameter of
the servlet expires after the last non-heartbeat request
.”

non-heartbeat request?

So, my question is; a device that runs a browser in the background (Apple iOS, Andriod, Windows Mobile, etc); if they are still running javascript on their pages, then those hearbeats are still running, hence, a session is kept alive indefinitely if that user never bothers to close the page in the browser, which is quite common with mobile devices. I understand that some OS’s pause javascript (or a page) that is pushed to the background, but I suspect some do not and as the technology progresses and processing power becomes more powerful, batteries last longer and data becomes cheaper then this will certainly become a major issue as many vendors will certainly allow background browsers to continue to run normally without pausing. Having said that, I’m not as concerned about the future as I am about the “now”, as it’s entirely possible there are devices today that do not pause background browser sessions and the thought of sessions being kept alive forever is sort of a deal breaker for me when it comes to the way Vaadin works.

But to your answer; I’m not sure how
closeIdleSessions
 answers or solves that problem as those running background processes will not be “non-heartbeat request”.

Btw: I’ve read that article before.

Having said that and as an aside; I really don’t understand why there is such a strong session dependency for events? I would like to see Vaadin eliminate or significantly reduce its dependency on sessions.

I suspect Vaadin creates a bigger problem for Developers and System Admins than what the framework is attempting to solve.

5

Jason,

“non-heartbeat request” is all comunication made by the user that interacts with the application, like clicks, data input,etc.
If the the user let the browser in background, there will be only “heartbeat request” and after the session timeout it will be closed if
closeIdleSessions
is true.

By the way, Sessions is not related to vaadin but to servlet specification.

Att

6

Yes. I hope it didn’t come across that I didn’t know what session were. I had said "
I really don’t understand why there is such a strong
session
dependency
 for events
?" I don’t think that’s the same as me saying (implied or otherwise) that I don’t know or understand what sessions are. :slight_smile:


In regards to closeIdleSessions:

If I understand what you’re saying; if
closeIdleSessions
 is
true
, regardless of heartbeat, the session will be closed after the session timeout has exceeded its set duration?

But in truth, a session will be expired regardless if the user clicks a button, enters data, because it has reached its duration and expired on the backend. So when a user clicks on button, or enters data, what’s really happening is the servlet/framework is detecting “no session”. So therefore the session doesn’t expire AFTER the last non-heartbeat request, but the user is only NOTIFIED the session has expired AFTER the the last or next non-heartbeat request, yes?

There’s a difference and I think the docs need to be made more clear what that process is exactly.


Update
:
I’ve just read this hoping it would offer greater clarification, but it doesn’t:
https://vaadin.com/wiki/-/wiki/Main/Cleaning+up+resources+in+an+UI

Does
closeIdleSessions
 when set to
true
,
disable
 heartbeat? When
closeIdleSessions
 is
true
, will the session continue as long as there’s user interaction? Or, does it close exactly when the session is set to expire regardless of hearbeat and user interaction?

7

Jason,

I think you misunderstand heartbeat and session timeout.


Heartbeat
- Used by the server to detect if the client is ‘alive’, e.g. the tab of the application or entire browser is closed. Let’s say a session timeout of 120 (3 hours) and heartbeat 300 (5 minutes), after 15 minutes without any heartbeat getting into server, the session will be closed.


Session
- The sessions times-out if there is no communication at all. if there is any comunication, like a click or heartbeat, the session time begins again from zero.


closeIdleSessions- True
: is like heartbeats not resetting session time.

Att

8

Ok, I think you mean well, but your answers seem to invoke more questions – respectfully.


Here’s how I understand Heartbeat:

Sent by the client every 5 minutes (by default) to the server, to keep the session alive. Heartbeat is merely just another request to the servlet/session. Java sessions keep-alive when there’s activity.


Sessions
:
Java sessions remain active as long as there is activity within a session timeout period and reset their timeout based on last activity. So, if sessions are set for 3 hours, if a user clicks a button, the session will persist for another 3 hours from that point.


CloseIdleSessions
:
I think what you’re saying is that the servlet/framework ignores heartbeats if this is set to true.

But now, I need clarification on what you said here:



“Let’s say a session timeout of 120 (3 hours) and heartbeat 300 (5 minutes), after 15 minutes without any heartbeat getting into server, the session will be closed.”

Java sessions expire after no activity and after the (or a) set time. In this example, Java sessions will expire in 3 hours. If the user closes their browser, no more heartbeats will be sent, so the (or a) Java session should simply persist for 3 hours from that point on and after that users last interaction (or heartbeat). So, when you say “Session” are you meaning a
Java Servlet Session
 or a
UI Session
 (ie. User session, specific to Vaadin itself, but not a Java Servlet Session)?

What you’re saying is even though (Java Servlet) sessions are set to expire in 3 hours, if the server doesn’t receive a heartbeat in 15 minutes (5 x 3), then it will expire the session right then, freeing memory?

What mechanism is responsible for expiring a 3 hour session in 15 minutes, on the server side? This is a Vaadin thing, not a servlet feature, yes?

CloseIdleSessions set to true tells the application to ignore heartbeats and simply expire after 3 hours (in this example), pending no user interaction within that time, yes? Otherwise if closeIdleSessions is set to false, then if there’s no heartbeat OR user interaction in 15 minutes (regardless of session timeout duration), kill the session, yes?

9



“What mechanism is responsible for expiring a 3 hour session in 15 minutes, on the server side? This is a Vaadin thing, not a servlet feature, yes?”

-yes, because there is no effective way to detect when the browser or tab is closed, then the heartbeat method.



“​So, when you say “Session” are you meaning a Java Servlet Session or a UI Session (ie. User session, specific to Vaadin itself, but not a Java Servlet Session)?”

  • Java Servlet Session (HttpSession): Take into account that the httpsession is tied to a single browser, and all frames/tabs opened in this browser share the same session. When a session is closed, all UI Sessions are closed.

Att

10

Ok, so my understanding now, based on everything you said is this:


  1. CloseIdleSessions
     set to
    true
     tells the application to ignore heartbeats and simply expire the Java Servlet Session after 3 hours (in this example), pending no user interaction within that time.

  2. Otherwise if
    closeIdleSessions
     is set to
    false
    , if there’s no heartbeat OR user interaction by 15 minutes (regardless of a 3 hour Java Servlet Session timeout duration), the session is killed then, freeing memory, by a Vaadin server side process.

Please give a thumbs-up if my understanding is correct.

11

Almost there!



“1. CloseIdleSessions set to true tells the application to ignore heartbeats and simply expire the Java Servlet Session after 3 hours (in this example), pending no user interaction within that time.”

  • Yes. If the browser/tab remains open, if not then is closed in 15 minutes(in this example).



“2. Otherwise if closeIdleSessions is set to false…”

-No. If the browser/tab remains open the heartbeat keeps the session alive indefinitely. Then when the browser/tab is closed the session will expire in 15 minutes.

Att

12

From your answer above, even with
closeIdleSessions
 set to
true
, even though heartbeats will be
ignored
, the session will expire in 15 minutes, just as if closeIdleSessions was set to false. Is that what you’re saying?


Please clarify:

CloseIdleSessions = TRUE, ignore heartbeat, yes? Then there’s no way to determine if the browser/tab is still open, so the Java Session will
not
 expire in 15 minutes, but in 3 hours, yes? Otherwise CloseIdleSessions = FALSE, heartbeat used, then if no heartbeat detected in 15 minutes, close.

13

Read carefully please.




closeIdleSessions | browser/tab | Session Close


  1. true open after 3 hours of the last user interection
  2. true closed 15 minutes
  3. false open alive indefinitely
    3.false closed 15 minutes

Att

14


Ok, that’s better.
 So then, heartbeat
isn’t
 being ignored, its still being used, but only to detect if the browser/tab is still around, otherwise, the session is only being kept alive by user interaction. Thank you, that really clarifies.



This information should be added to the documentation for clarification.

[font=courier new]


closeIdleSessions | browser/tab | Session Close

  1. true open after 3 hours of the last user interection
  2. true closed 15 minutes
  3. false open alive indefinitely
  4. false closed 15 minutes
    [/font]
15

I am not sure, it the table is right. What’s closed after 15 minutes in cases 2) and 4) are inactive UIs. The session itself is closed by container after 3 hours if no other UI is open and no user interaction occurs. If you close the last UI in your session, then the UI remains active until session timeout because the hearbeat cleanup is activated on the end of each request and removes inactive UIs that belong to the same session only.

The point of the heartbeat mechanism is to remove other UIs in the same session that are no longer active. If you open a UI, then close it, and do nothing else with the application, it will live until the session expires, regardless the heartbeat settings. If you open another UI and interact with it, the first UI is cleaned up only if the second UI belongs to the same sesssion.

16

yaa right Robert Carnecky