tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier>
Subject Re: [OT?] control of session timed out with tomcat
Date Fri, 21 Oct 2011 21:23:10 GMT
Mark Thomas wrote:

>>>> Of course in all this, my basic assumption is that currently, Tomcat
>>>> keeps session information (including the expiration data) in some
>>>> location which requires an I/O action to access.

>>> That assumption is incorrect. Which pretty much invalidates the rest of
>>> the points below.
>>> Again, I *strongly* encourage you to look at the current implementation
>>> before suggesting improvements.

>> In a case like this one for instance, I would not even know where to
>> start, about looking up the particular piece of code involved here. And
>> when I would find it, which may take me a couple of hours, I am not sure
>> that I would even understand that code.
> You might be surprised at simple the code is.
> (start at line 515)
> (start at line 645)

Right, that's what I'm saying :

I didn't know the above, and maybe 1% of the people on this list would know that.
I would probably have started with
then, among the 40-odd items mentioned there, I might have spotted the one named "session"

(a clue, that), and clicked on it.

Then I would be at
and have a choice of only 10 Java items, out of which I would not know for sure where I 
would find the right one.
Even if by selective luck I had clicked on the one named "", it would 
still have taken me quite a while to locate the interesting section at line 515.

But then, the code which I find there is still quite a puzzle for me, considering that you

say below that the sessions are in a ConcurrentHashMap.
All I see there is an array, and a loop through that array.
I also don't understand what is actually done there, except apparently counting the 
invalid sessions in expireHere (but apparently only for the benefit of logging it when in

debug mode).

So let's go to the other pointer you provide above (StandardSession, line 645).
There I see :

  public boolean isValid() {
647 	if (this.expiring) {
648 	return true;
649 	}
651 	if (!this.isValid) {
652 	return false;
653 	}

which, for my very basic knowledge of Java, is already quite confusing.
At line 651, is this a recursive call to the same method, or something else ?
But this is still not telling me what "session" really is; the code does some calculations

based on the time and the expiration timeout, but this code does not actually seem to "do

anything" to the session thing, whatever it may be.  It just returns a boolean value.
Ah, but I've aso seen a call to findSessions() somewhere, so let's look for that.
It is back in ManagerBase, line 703.

703 public Session[] findSessions() {
705 	return sessions.values().toArray(new Session[0]);
707 	}

Well at least I guess that this explains the sessions array above, kind of (except that I

do not understand the "new Session[0]" argument).

I ain't seen a ConcurrentHashMap yet, nor any indication so far as to where the session 
information is really kept.  So far it /could/ be on disk, or just as well on a set of 
scrolls attached to pigeon legs. (*)

I am jesting a bit, but my point is still : for someone fluent in Java and Tomcat code, 
this may be a breeze.  But I am ready to bet that for 95% of the people coming to this 
list for information, it is everything but.
And after all, that's exactly why there are thousands of users of this list, and only a 
handful of Tomcat code committers.

And that's fine, and I am very happy to have some of these committers on this list, to 
explain in plain English how it really works, and rebutt the silly suggestions which I 
make out of ignorance.

But telling the average bloke here, that he should go and browse the code, before he makes

a silly suggestion out of the goodness of his heart, may be a bit disingenuous, no ?
This is the Tomcat users' list, not the dev's one.

> For background, the sessions are in a ConcurrentHashMap, keyed by
> session ID.

So far thus, I am very happy to take your word for it, because I could not find this in 
the indicated code. (*)


> If anyone is going to suggest changes to improve the current
> implementation then, yes, I think they need to know what the current
> implementation is before they make those suggestions. It simply isn't
> possible to state that "B is likely to perform better than A" without an
> understanding of what A is.

I stand chastised.
In my imagination, a "session" is something which could potentially contain a lot of data

(what the application developer chooses to save in it, right ?), and could also need to be

stored persistently across Tomcat restarts. Consequently (but wrongly) I assumed that at 
least the bulk of it was kept otherwise than in memory.
Which evidently is not true.
And which does indeed make my previous suggestions rather silly.

> In this case, you pretty much ended up describing exactly how Tomcat
> currently manages sessions. 

For someone not having seen the code previously, that's pretty good, no ?
(I will take it as a compliment anyway.)

(*) I have since found it.  I was looking for a Session or Sessions object, but it is the

ManagerBase object (?) which contains this ConcurrentHashMap of sessions.

What I still don't find is the actual code that is being run by the background thread to 
scan the ConcurrentHashMap and delete expired sessions.  Where does that one live ?

By the way, in the code, aren't the comment lines 130-133 
redundant/duplicates of the lines 119-123 ?

Another question is ( :
705 	 return sessions.values().toArray(new Session[0]);

this means that finally all the values (StandardSession objects) of the ConcurrentHashMap

get copied into an array of StandardSession objects, right ?
Isn't this quite heavy, if the sessions are "bulky" (iow have a lot of attributes in them

saved by the application) ?
Or is this just an array of "object references" ?

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message