Hi,
does anyone uses non-default heartbeat and session timeouts?
I consider using 5 min session timeout and a heartbeat intervall of 2 minutes. To remove sessions early if a user closed all Browser/Tabs.
But what happens if a user has some Tabs open and the server puts some Tabs into sleep (energy saving settings), then no heartbeat will be made or?
My experience is that 30 seconds pr less is too short for heart beat interval and can lead to unexpected closing of the session ehen Browser tab sleeps. I recommend thus minimun one minute. Remember to set closeIdleSessions to true as well.
(Browsers throttle JS intervalls even down to 1 / minute nowadays)
Hi,
vaadin.closeIdleUIs is per default set to false?
Does that mean, das a closed UI is removed after session time out?
But would it not make sense to remove a UI directly once its not open anymore?
@Leif i think this topic relates good to our previous conversation. I have an admin view where i count e 200 sessions but only 101 active UIs.
Am i right, that those 99 sessions (without UI) are kept because closeIdleUIs or closeIdleSessions is per default false?
I dont have an idea why there a so much idle sessions with no UI. Because the users for example work in a view. Close the Tab and then some minutes later they come. In this case the session should be reused or?
Do you have any idea how to check where those sessions come from? But for from my POV those sessions with no UI, can be removed earlyer. They are unnecassary or?
Yes, This depends ofcourse what you want and what is the desired behavior. Say you have session time out of 30 mins, and you close browser tab, yes the UI is closed almost immediately as Vaadin will catch the beacon request from the browser (Safari, Chrome, Edge) and the session will be lingerign there until session timeout comes.
Naturally if your user reopens the app, the session is reused. And session timeout is reset.
There are very different kinds of apps. Some are open for whole office hours, some apps are used in very short sessions. I.e. user comes in, checks one thing, and then goes away. In that case it makes sense to make the session timeout short, say 5 mins or so. It may be also making sense to have closeIdleSessions=true, as then we are kicking the user out in 5 mins (we think he just forgot to close the tab).
The idea of the default settings is not that they would fit all scenarios.
Thank you. Its a mix of some users stay logged in and other come, stay 2 minutes and go.
I see a problem when users has “auto delete website data” activated in their browser. Then each time they close the browser and visit the app, a new session gets created. I dont know it closing a tab can also remove its cookies in some browser (?).
Currently i see that that i have for examle 180 Sessions, but only 80 has a active view. The others will be kicked after http.timeout right? Actuall i have only http.timeout set to 12 minutes closeIdleSessions is default (so false)
But is it really woth it to handle those sessions? Its not that big without an UI attached isnt it?
Would like to come back to this topic. I have implemented Remember Me Login, so if a user visit the page an leave, why is the session not destroyed immediately? Once he comes back , he will be auto logged in during remember me token.
Isnt there a way to remove a session once no UI is opened anymore? Would save some space or?
There is not really a nice solution. E.g. closing session on UI detach will have side effects. E.g. when you refresh page, you will be kicked out from the app. Probably this is not wanted.
What you can think about is to have cleaner thread running on background, which closes sessions when they do not have UIs with some grace period. I.e. then refresh should work if the session is not immediately cleaned, or if you use PreserveOnRefresh.
There was add-on for Vaadin 8 with similar idea
Note, this code is not exactly applicable for Spring Boot applications, as Spring integration extends the Servlet. So you need to do this via Spring APIs instead. Also it is not preferable to use Thread directly with modern Java, use ExecutorService with virtual thread pool instead. But anyway the code serves as food for thought.
And this approach is used also by servlet containers to wipe orphaned HttpSessions, like in Tomcat it is called CatalinaUtility.
Hi Tatu, thank you!
If we use remember me, its will relogin and should have any side effect or?
Good point. If you have token based authentication with remember me, then actually there is no UX problem, as the login screen will be skipped.
Is there any known implementation available on your side? Otherwise i would embed it into my VaadinServiceInitListener or create a global one like:
public class GlobalDetachListener implements VaadinServiceInitListener {
@Override
public void serviceInit(ServiceInitEvent event) {
event.getSource().addUIInitListener(uiEvent -> {
UI ui = uiEvent.getUI();
ui.addDetachListener(detachEvent -> {
VaadinSession session = ui.getSession();
if (session == null) {
return;
}
session.lock();
try {
int remainingUis = session.getUIs().size();
if (remainingUis == 0) {
session.getSession().invalidate();
session.close();
}
} finally {
session.unlock();
}
});
});
}
}
What do you think about it? Sounds like a good idea. I think its not necassary to keep the session in memory if the user has no UI open anymore
Instead of session.lock() .. session.unlock() pair I would use session.access(..) instead. In general it is trial and error learning for you. I can’t say with absolute certainty it will work, but it could. It really boils to nitty gritty details of your app. Applying something like this, will mean that refreshing browser page will restart the session and loading everything from the start and all unsaved data in session will be lost. Will this be better from resource consumption wise vs. session waiting to be cleaned by CatalinaUtility later (e.g. if you run Tomcat), it is very hard to say without knowing the whole context. E.g. will your users use page refresh a lot? Do you have anything important in session scope that needs to be preserved?
Refresh should be used very less i guess. Data from
@Data
@Component
@VaadinSessionScope
public class VaadinSessionData {
//stuff
}
would be lost in this case i guess? There are saved some user data like id, username etc. But the username could be read from the AuthContext of Spring, right?
If you use Vaadin’s Spring Security helpers, it has an AuthContext customizer, which changes AuthContext store to VaadinSession, which would be dropped upon refresh if you have the solution you proposed.
I have tested itbut after closing the last tab of the app it still counted 1 UI anyhow hm.
Yes, that is expected as the cleaning up of the last UI is done later. If you want to get this done more eagerly, you need the clean-up thread solution I pointed earlier.