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.
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/session/ManagerBase.java?view=annotate
(start at line 515)
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/session/StandardSession.java?view=annotate
(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
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/
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
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/session/
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 "ManagerBase.java", 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() {
646
647 if (this.expiring) {
648 return true;
649 }
650
651 if (!this.isValid) {
652 return false;
653 }
etc..
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() {
704
705 return sessions.values().toArray(new Session[0]);
706
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 ManagerBase.java code, aren't the comment lines 130-133
redundant/duplicates of the lines 119-123 ?
Another question is (ManagerBase.java) :
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: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
