Pascal,
On 1/8/25 2:20 PM, Pascal Rigaux wrote:
On some applications we have:
- quite low number of users most of the time
- high number of users twice a year
These applications store quite a lot of information in session.
To cope with the surge of users, we would need to:
- either increase mx (Java max memory)
- or use short session timeout (lifetime)
- or use horizontal scaling (k8s... but we currently have no such
solutions)
The best solution for us would be a "maxActiveSessions" setting which
would set a high bound to the number of sessions,
but compared to current implementation, it would allow new sessions and
expire old sessions.
We mostly achieved this with a cron (1) calling a script (2): it uses
tomcat-manager to force a shorter lifetime when there is a lot of sessions.
Since it would be nicer to have this behavior directly in tomcat, I did
it using a small class extending StandardManager (2).
I wonder if this could be useful to other users?...
I would veto the behavior in the subject line if proposed for adding to
Tomcat.
It would allow anyone to force a logout of all current users at will
just by making any request that causes an unauthenticated session to be
created.
Instant DOS.
Your custom class in (2) does not do exactly what the subject says.
Instead, it sets a "goal" session count and will expire the oldest
sessions until it reaches that goal.
But, I think it suffers the same DOS problem because it prefers new
sessions to old ones. If an attacker creates a bunch of new sessions
quickly, then all real users will be logged-out.
If your application is hosted in a location where all access is trusted,
then this is I guess an okay situation, but those cases are appropriate
for a custom session manager like you built.
I would encourage you to post your code on GitHub or similar and give
that away for free, but I think inclusion in Tomcat is unlikely.
If you are worried about heap space for large sessions, I might suggest
that you use WeakReference objects wrapping your large session
references. This will allow the GC to clear those references when it
experiences memory pressure and evict those objects. Your application
can detect the disappearance of the object and re-load it from primary
storage.
Of course, you can only do this with things like cached data where there
is a primary data store to fall-back to.
If you have large amounts of "working" data in your sessions, I would
recommend moving that data out of the session into a dedicated "working"
data store that has more flexibility than your application's heap space.
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
