Re: [OT?] control of session timed out with tomcat
Mark Thomas wrote:
On 20/10/2011 17:01, Tim Watts wrote:
On Thu, 2011-10-20 at 16:35 +0100, Mark Thomas wrote:
On 20/10/2011 16:22, André Warnier wrote:
Hassan Schroeder wrote:
On Thu, Oct 20, 2011 at 7:52 AM, André Warnier a...@ice-sa.com wrote:
1) Tomcat (probably) doesn't spend its time all the time scanning stored
sessions to see if one has expired, and deleting it.
Actually, it does. That's what session listeners depend on.
So, for example, I can have a ShoppingCart with a method like
public void valueUnbound(HttpSessionBindingEvent httpsessionbindingevent)
{
empty(); /* remove reserved status from items */
}
If the session times out without the cart contents being purchased,
the cart returns any items it contains to inventory. Very handy :-)
You mean that if there are 500 sessions active, Tomcat spends its time
checking all of them repeatedly on the off-chance that one has expired ?
It is handled by the background processing thread. By default that
thread runs every 10 seconds and ManagerBase triggers a session
expiration check every 6 runs by default. So in short, they are checked
roughly every 60s. The test is pretty simple so it doesn't take very
long at all.
Or is there a smarter algorithm implemented there ?
Such as? I'm open to ideas here (maybe not for this exact problem but
certainly the general one).
Not necessarily claiming better but:
* find the oldest session
This can change dynamically since application code can change the
session expiration time at any point.
* go to sleep until it's ready to expire (since you know nothing
interesting will happen before then)
* wake up and expire sessions that need expiring
* repeat
Of course, this would require a dedicated thread. If the background
thread handles more tasks than just expiring sessions there's probably
not much gain in doing this approach. Or you could use the 'find oldest
session' value to compute how many work cycles to skip until the next
actual check. Is the complexity worth the savings in CPU cycles? Eh,
probably a wash. Could set a minimum threshold and only use the computed
value if it's greater than the threshold. Incorporate the computation as
part of the session scan.
But you did ask... :-)
If session expiration time was constant, this would be fine.
Unfortunately, that is not the case.
How about..
I am assuming that at each access to the application, Tomcat updates the expiration time
of the session if any (that is, it sets a new date/time at which this session will be
considered as expired, being now + timeout).
So Tomcat, at any time, could maintain an ordered list of sessions with their timeout
timestamps (sorted by increasing expiration timestamp).
Now whenever the background thread goes into its check for expired sessions cycle, it
could start at the beginning of the sorted list, and stop as soon as it encounters an
entry with an expiration time which is later than now, because any entry beyond that
point is of course unexpired.
The sorted list needs to contain only the session-id and current expiration timestamp, so
it should not be that costly in terms of memory. (*)
In my personal experience, systems nowadays tend to be limited more by their disk I/O
speed than by CPU usage. Despite the more complex logic required by keeping the ordered
list ordered, and considering that sessions are usually created/kept for a considerable
length of time, I have a feeling that this might provide a performance boost, all the more
important as the number of sessions increases.
Also, when checking a session for expiration, Tomcat would not actually need to read each
session's info to get its expiration time and decide to delete the session. It could just
check the entry in the list, and delete the session info immediately if it is expired,
without needing to read it.
(*) I would even not be surprised if there existed already in memory some form of table
representing the current sessions.
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [OT?] control of session timed out with tomcat
On 21/10/2011 10:05, André Warnier wrote: I am assuming that at each access to the application, Tomcat updates the expiration time of the session if any (that is, it sets a new date/time at which this session will be considered as expired, being now + timeout). Rather than making incorrect assumptions, you could check the source code. So Tomcat, at any time, could maintain an ordered list of sessions with their timeout timestamps (sorted by increasing expiration timestamp). That is do-able. Now whenever the background thread goes into its check for expired sessions cycle, it could start at the beginning of the sorted list, and stop as soon as it encounters an entry with an expiration time which is later than now, because any entry beyond that point is of course unexpired. The sorted list needs to contain only the session-id and current expiration timestamp, so it should not be that costly in terms of memory. (*) In my personal experience, systems nowadays tend to be limited more by their disk I/O speed than by CPU usage. Despite the more complex logic required by keeping the ordered list ordered, and considering that sessions are usually created/kept for a considerable length of time, I have a feeling that this might provide a performance boost, all the more important as the number of sessions increases. Also, when checking a session for expiration, Tomcat would not actually need to read each session's info to get its expiration time and decide to delete the session. It could just check the entry in the list, and delete the session info immediately if it is expired, without needing to read it. With this approach the question is which is faster: a) iterating all of the sessions once a minute (or frequency of choice) and discarding all those with (now - last accessed) timeout b) maintaining a list of sessions ordered by expiration time which is updated on every request associated with a session I have a hard time believing that: 1. b) isn't significantly more expensive 2. b) doesn't have all sorts of issues in a multi-threaded environment Hard data will convince me otherwise but at this point I suspect b) is considerably worse. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [OT?] control of session timed out with tomcat
Mark Thomas wrote: On 21/10/2011 10:05, André Warnier wrote: I am assuming that at each access to the application, Tomcat updates the expiration time of the session if any (that is, it sets a new date/time at which this session will be considered as expired, being now + timeout). Rather than making incorrect assumptions, you could check the source code. So Tomcat, at any time, could maintain an ordered list of sessions with their timeout timestamps (sorted by increasing expiration timestamp). That is do-able. Now whenever the background thread goes into its check for expired sessions cycle, it could start at the beginning of the sorted list, and stop as soon as it encounters an entry with an expiration time which is later than now, because any entry beyond that point is of course unexpired. The sorted list needs to contain only the session-id and current expiration timestamp, so it should not be that costly in terms of memory. (*) In my personal experience, systems nowadays tend to be limited more by their disk I/O speed than by CPU usage. Despite the more complex logic required by keeping the ordered list ordered, and considering that sessions are usually created/kept for a considerable length of time, I have a feeling that this might provide a performance boost, all the more important as the number of sessions increases. Also, when checking a session for expiration, Tomcat would not actually need to read each session's info to get its expiration time and decide to delete the session. It could just check the entry in the list, and delete the session info immediately if it is expired, without needing to read it. With this approach the question is which is faster: a) iterating all of the sessions once a minute (or frequency of choice) and discarding all those with (now - last accessed) timeout b) maintaining a list of sessions ordered by expiration time which is updated on every request associated with a session I have a hard time believing that: 1. b) isn't significantly more expensive 2. b) doesn't have all sorts of issues in a multi-threaded environment Hard data will convince me otherwise but at this point I suspect b) is considerably worse. Allright, so how about a half-way house to start with ? Keep the list in some thread-safe table, indexed by session-id, and just scan the table. Updating the corresponding session entry at each request should be cheap. 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. If so, an immediate benefit of having a table in memory, may be that when a request comes in with a session-id, the check of whether this session-id is still valid may be speeded up significantly (as opposed to try to actually get the session info through an I/O and maybe failing). And even if found in the table, the check on the expiration time would be quick too. And if it is expired, deleting the entry from the table, and deleting the session info through an I/O, may still be faster than first retrieving the session info from disk. Re-thinking about the above, an easier way to achieve a similar effect, may be to arrange to store all session info onto something like a RAM-disk of course. Basically my feeling is this : assuming for example 1000 on-going sessions, the background thread needs to do at least 1000 I/O's (and probably many more) each time it checks for session expiration. And this only to compare now with the session's expiration data. Intuitively, this seems like a significant waste of I/O bandwidth, which could be avoided at the cost of a bit of RAM. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [OT?] control of session timed out with tomcat
On 21/10/2011 11:42, André Warnier wrote: Allright, so how about a half-way house to start with ? Keep the list in some thread-safe table, indexed by session-id, and just scan the table. Updating the corresponding session entry at each request should be cheap. 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. Mark If so, an immediate benefit of having a table in memory, may be that when a request comes in with a session-id, the check of whether this session-id is still valid may be speeded up significantly (as opposed to try to actually get the session info through an I/O and maybe failing). And even if found in the table, the check on the expiration time would be quick too. And if it is expired, deleting the entry from the table, and deleting the session info through an I/O, may still be faster than first retrieving the session info from disk. Re-thinking about the above, an easier way to achieve a similar effect, may be to arrange to store all session info onto something like a RAM-disk of course. Basically my feeling is this : assuming for example 1000 on-going sessions, the background thread needs to do at least 1000 I/O's (and probably many more) each time it checks for session expiration. And this only to compare now with the session's expiration data. Intuitively, this seems like a significant waste of I/O bandwidth, which could be avoided at the cost of a bit of RAM. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [OT?] control of session timed out with tomcat
Mark Thomas wrote: On 21/10/2011 11:42, André Warnier wrote: Allright, so how about a half-way house to start with ? Keep the list in some thread-safe table, indexed by session-id, and just scan the table. Updating the corresponding session entry at each request should be cheap. 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. Mark, with all due respect and really sincere appreciation for your and other Tomcat committers' work, not all people who use Tomcat, and who sometimes try to be helpful in this forum, are Java developers, or even software developers in general. And such people also have other things which occupy their time for $ reasons. What I'm saying, is that what for you or other Tomcat committers may be a simple thing of 2 minutes to look up and understand, or which you do not even need to look up because you already know it for being immersed in it all day, is not necessarily so simple for others. 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. This is not out of laziness. It just so happens that 98% of my time is spent on other things than Java and Tomcat, and the remaining 2% I like to keep for reading the spirited correspondence on this list and trying to help on matters where a deep knowledge of Java and Tomcat code is not essential. I apologise thus if you feel that I am wasting your time by making unwarranted suppositions or assumptions. Even when making improper assumptions and suggestions, it is on the base of a desire to help. I can of course stop this at any time, if you feel that my attempted contributions do more harm than good. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [OT?] control of session timed out with tomcat
On 21/10/2011 13:43, André Warnier wrote: Mark Thomas wrote: On 21/10/2011 11:42, André Warnier wrote: Allright, so how about a half-way house to start with ? Keep the list in some thread-safe table, indexed by session-id, and just scan the table. Updating the corresponding session entry at each request should be cheap. 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. Mark, with all due respect and really sincere appreciation for your and other Tomcat committers' work, not all people who use Tomcat, and who sometimes try to be helpful in this forum, are Java developers, or even software developers in general. And such people also have other things which occupy their time for $ reasons. What I'm saying, is that what for you or other Tomcat committers may be a simple thing of 2 minutes to look up and understand, or which you do not even need to look up because you already know it for being immersed in it all day, is not necessarily so simple for others. 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) For background, the sessions are in a ConcurrentHashMap, keyed by session ID. This is not out of laziness. It just so happens that 98% of my time is spent on other things than Java and Tomcat, and the remaining 2% I like to keep for reading the spirited correspondence on this list and trying to help on matters where a deep knowledge of Java and Tomcat code is not essential. I apologise thus if you feel that I am wasting your time by making unwarranted suppositions or assumptions. Even when making improper assumptions and suggestions, it is on the base of a desire to help. I can of course stop this at any time, if you feel that my attempted contributions do more harm than good. 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. In this case, you pretty much ended up describing exactly how Tomcat currently manages sessions. Was this a waste of my time? If a few more people now have a better understanding of how session management works then no, I don't think it was a waste of my time. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [OT] control of session timed out with tomcat
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tim, On 10/20/2011 7:01 PM, Tim Watts wrote: This was a while ago -- no HttpSessionListeners available -- so we couldn't easily persist the session and recall it when the user logged in again. Wow. What were you using, Apache JServ? Tomcat 3.x? I don't see from the API javadocs when HttpSessionBindingListener was introduced (it just says $Version$ in 2.5 and nothing at all in 3.0), but that should have been around for a long time. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6hikoACgkQ9CaO5/Lv0PAYtgCgtzkREusG5n1oGmTtC1pyMzKS iIYAnRUBhxc8q+qZ0E77m1UQRQIrPANX =P4Wf -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [OT] control of session timed out with tomcat
On Fri, 2011-10-21 at 11:05 -0400, Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tim, On 10/20/2011 7:01 PM, Tim Watts wrote: This was a while ago -- no HttpSessionListeners available -- so we couldn't easily persist the session and recall it when the user logged in again. Wow. What were you using, Apache JServ? Tomcat 3.x? It was 3.x I believe. Yes, I am that old. Eh, you kids today with your new fangled session listeners and what not. Back in the day we just let the user's work vanish into thin air ...and they were GRATEFUL! :-) I don't see from the API javadocs when HttpSessionBindingListener was introduced (it just says $Version$ in 2.5 and nothing at all in 3.0), but that should have been around for a long time. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6hikoACgkQ9CaO5/Lv0PAYtgCgtzkREusG5n1oGmTtC1pyMzKS iIYAnRUBhxc8q+qZ0E77m1UQRQIrPANX =P4Wf -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [OT] control of session timed out with tomcat
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tim, On 10/21/2011 2:10 PM, Tim Watts wrote: On Fri, 2011-10-21 at 11:05 -0400, Christopher Schultz wrote: On 10/20/2011 7:01 PM, Tim Watts wrote: This was a while ago -- no HttpSessionListeners available -- so we couldn't easily persist the session and recall it when the user logged in again. Wow. What were you using, Apache JServ? Tomcat 3.x? It was 3.x I believe. Yes, I am that old. Eh, you kids today with your new fangled session listeners and what not. Back in the day we just let the user's work vanish into thin air ...and they were GRATEFUL! :-) I was there for the 2.2-2.3 switch as well. I remember being handed a server runbook that included Apache JServ, and configuring everything was a tedious nightmare. I understand why some people post to the list saying my configuration doesn't work and you find they're using a TC 4.x server.xml file with TC 7.x: that's what the runbook says, so they do it. I distinctly remember personally upgrading our own standard library code to move from the whole getValue/setValue to getAttribute/setAttribute. My employer, for whatever reason, had also implemented their own session management strategy and wired it into their own app framework (I use that term *very* loosely). I re-factored it to use standard HttpSessions under the hood and then got to delete /lots/ of (IMO) completely useless code. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6h3YoACgkQ9CaO5/Lv0PDkuwCfeBlt55GCpcsGRBm10gX8rnWf 49UAnR96Q+Vdzpc4k5EpC5srpJuAJWCY =HM2M -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [OT?] control of session timed out with tomcat
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
control of session timed out with tomcat
Hi my friends, I want to ask you all, If there is a way to control the timed out of sessions with tomcat, what I need is when the session timed out, automatically the user is redirected to the login page, Is this possible to do that from tomcat?, I mean, tomcat triggers some event to the user with session timed out, with no need user interaction. I know that the time of inactivity of the session is setup in web.xml, with that I have no problem, what I need is just redirect to a login page when the session timed out. I am working with tomcat 7.0.20 and JDBCRealm for authentication. Thanks in advance. -- Alejandro Soto M.
Re: control of session timed out with tomcat
On Thu, 2011-10-20 at 09:51 -0400, Alejandro Soto wrote: Hi my friends, I want to ask you all, If there is a way to control the timed out of sessions with tomcat, what I need is when the session timed out, automatically the user is redirected to the login page, Is this possible to do that from tomcat?, I mean, tomcat triggers some event to the user with session timed out, with no need user interaction. I know that the time of inactivity of the session is setup in web.xml, with that I have no problem, what I need is just redirect to a login page when the session timed out. You mean when a browser is just sitting idle and the session times out on the server, the browser is automatically redirected to the login page? If so, see JavaScript and timers (all JavaScript caveats apply). But Tomcat itself cannot reach out and trigger events at the client. Also, they will not be redirected to the login page if they are not already at a page that requires authentication. You can't directly redirect to the login page. So the JavaScript script would need to redirect to a protected page when the timer pops (could be the page they're on, could be something else). I am working with tomcat 7.0.20 and JDBCRealm for authentication. Thanks in advance. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: control of session timed out with tomcat
On Thu, Oct 20, 2011 at 6:51 AM, Alejandro Soto smalejan...@gmail.com wrote: Hi my friends, I want to ask you all, If there is a way to control the timed out of sessions with tomcat, what I need is when the session timed out, automatically the user is redirected to the login page, Is this possible to do that from tomcat?, I mean, tomcat triggers some event to the user with session timed out, with no need user interaction. No. That's not how the web works :-) What you *can* do is put a meta-refresh tag in the head of each page (with the time set the same as your session timeout) that redirects to a protected resource, which will bring up the login page. HTH, -- Hassan Schroeder hassan.schroe...@gmail.com http://about.me/hassanschroeder twitter: @hassan - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: control of session timed out with tomcat
On Thu, 2011-10-20 at 10:06 -0400, Tim Watts wrote: On Thu, 2011-10-20 at 09:51 -0400, Alejandro Soto wrote: Hi my friends, I want to ask you all, If there is a way to control the timed out of sessions with tomcat, what I need is when the session timed out, automatically the user is redirected to the login page, Is this possible to do that from tomcat?, I mean, tomcat triggers some event to the user with session timed out, with no need user interaction. I know that the time of inactivity of the session is setup in web.xml, with that I have no problem, what I need is just redirect to a login page when the session timed out. You mean when a browser is just sitting idle and the session times out on the server, the browser is automatically redirected to the login page? If so, see JavaScript and timers (all JavaScript caveats apply). But Tomcat itself cannot reach out and trigger events at the client. Also, they will not be redirected to the login page if they are not already at a page that requires authentication. You can't directly redirect to the login page. So the JavaScript script would need to redirect to a protected page when the timer pops (could be the page they're on, could be something else). I should also point out that this approach is somewhat kludgey because of the inherent latency problems when the session is close to expiration. But I don't know of a rock solid approach. You just have to have the timer pop sufficiently sooner than the session expiration -- for some value of sufficient. I am working with tomcat 7.0.20 and JDBCRealm for authentication. Thanks in advance. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: control of session timed out with tomcat
On Thu, 2011-10-20 at 07:08 -0700, Hassan Schroeder wrote: On Thu, Oct 20, 2011 at 6:51 AM, Alejandro Soto smalejan...@gmail.com wrote: Hi my friends, I want to ask you all, If there is a way to control the timed out of sessions with tomcat, what I need is when the session timed out, automatically the user is redirected to the login page, Is this possible to do that from tomcat?, I mean, tomcat triggers some event to the user with session timed out, with no need user interaction. No. That's not how the web works :-) What you *can* do is put a meta-refresh tag in the head of each page (with the time set the same as your session timeout) that redirects to a protected resource, which will bring up the login page. HTH, oh. yes, meta-refresh would be better than a timer. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: control of session timed out with tomcat
Hi, thanks for your replies, These are the only ways I have to do it?, I was reading something about filters, but I think only works with user interaction. Thanks. On Thu, Oct 20, 2011 at 10:08 AM, Hassan Schroeder hassan.schroe...@gmail.com wrote: On Thu, Oct 20, 2011 at 6:51 AM, Alejandro Soto smalejan...@gmail.com wrote: Hi my friends, I want to ask you all, If there is a way to control the timed out of sessions with tomcat, what I need is when the session timed out, automatically the user is redirected to the login page, Is this possible to do that from tomcat?, I mean, tomcat triggers some event to the user with session timed out, with no need user interaction. No. That's not how the web works :-) What you *can* do is put a meta-refresh tag in the head of each page (with the time set the same as your session timeout) that redirects to a protected resource, which will bring up the login page. HTH, -- Hassan Schroeder hassan.schroe...@gmail.com http://about.me/hassanschroeder twitter: @hassan - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org -- Alejandro Soto M. Cel: 705-63861
Re: control of session timed out with tomcat
On Thu, 2011-10-20 at 10:23 -0400, Alejandro Soto wrote: Hi, thanks for your replies, These are the only ways I have to do it?, I was reading something about filters, but I think only works with user interaction. Basically, that's all. Filters are only active during the request-response cycle. Once the response is sent, it's done. Strictly speaking, you could do some kind of ajax thing but that's far into crazy-land -- just a bad variation on what's already been suggested. Thanks. On Thu, Oct 20, 2011 at 10:08 AM, Hassan Schroeder hassan.schroe...@gmail.com wrote: On Thu, Oct 20, 2011 at 6:51 AM, Alejandro Soto smalejan...@gmail.com wrote: Hi my friends, I want to ask you all, If there is a way to control the timed out of sessions with tomcat, what I need is when the session timed out, automatically the user is redirected to the login page, Is this possible to do that from tomcat?, I mean, tomcat triggers some event to the user with session timed out, with no need user interaction. No. That's not how the web works :-) What you *can* do is put a meta-refresh tag in the head of each page (with the time set the same as your session timeout) that redirects to a protected resource, which will bring up the login page. HTH, -- Hassan Schroeder hassan.schroe...@gmail.com http://about.me/hassanschroeder twitter: @hassan - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: control of session timed out with tomcat
Alejandro Soto wrote: Hi, thanks for your replies, These are the only ways I have to do it?, I was reading something about filters, but I think only works with user interaction. The basic issues are these : 1) Tomcat (probably) doesn't spend its time all the time scanning stored sessions to see if one has expired, and deleting it. What it does is : when a new request comes in, and that new request has a session-id in it, then Tomcat looks for this stored session. If it finds it, it checks if it has expired, and if so, it deletes it and does as if the session had not been there in the first place. 2) even assuming that Tomcat would find out, without user interaction, that a session has expired, and wanted to send something somewhere, where would it send it ? It is not certain that the browser of that user still has a connection open with the server. And even if there was such a connection open, and Tomcat sent something on it, the browser isn't waiting for anything, since it has not requested anything. I wouldn't be surprised if the browser got very confused then. That's why you always need the browser to send something, to have Tomcat react and search for the session, and send an answer. Personally, I think that by trying to do this (in whatever way), you set yourself up for all kinds of bizarre happenings and side-effects. What is the problem you are trying to solve ? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: control of session timed out with tomcat
On Thu, Oct 20, 2011 at 7:52 AM, André Warnier a...@ice-sa.com wrote:
1) Tomcat (probably) doesn't spend its time all the time scanning stored
sessions to see if one has expired, and deleting it.
Actually, it does. That's what session listeners depend on.
So, for example, I can have a ShoppingCart with a method like
public void valueUnbound(HttpSessionBindingEvent httpsessionbindingevent)
{
empty(); /* remove reserved status from items */
}
If the session times out without the cart contents being purchased,
the cart returns any items it contains to inventory. Very handy :-)
FWIW,
--
Hassan Schroeder hassan.schroe...@gmail.com
http://about.me/hassanschroeder
twitter: @hassan
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [OT?] control of session timed out with tomcat
Hassan Schroeder wrote:
On Thu, Oct 20, 2011 at 7:52 AM, André Warnier a...@ice-sa.com wrote:
1) Tomcat (probably) doesn't spend its time all the time scanning stored
sessions to see if one has expired, and deleting it.
Actually, it does. That's what session listeners depend on.
So, for example, I can have a ShoppingCart with a method like
public void valueUnbound(HttpSessionBindingEvent httpsessionbindingevent)
{
empty(); /* remove reserved status from items */
}
If the session times out without the cart contents being purchased,
the cart returns any items it contains to inventory. Very handy :-)
You mean that if there are 500 sessions active, Tomcat spends its time checking all of
them repeatedly on the off-chance that one has expired ?
Or is there a smarter algorithm implemented there ?
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [OT?] control of session timed out with tomcat
On 20/10/2011 16:22, André Warnier wrote:
Hassan Schroeder wrote:
On Thu, Oct 20, 2011 at 7:52 AM, André Warnier a...@ice-sa.com wrote:
1) Tomcat (probably) doesn't spend its time all the time scanning stored
sessions to see if one has expired, and deleting it.
Actually, it does. That's what session listeners depend on.
So, for example, I can have a ShoppingCart with a method like
public void valueUnbound(HttpSessionBindingEvent httpsessionbindingevent)
{
empty(); /* remove reserved status from items */
}
If the session times out without the cart contents being purchased,
the cart returns any items it contains to inventory. Very handy :-)
You mean that if there are 500 sessions active, Tomcat spends its time
checking all of them repeatedly on the off-chance that one has expired ?
It is handled by the background processing thread. By default that
thread runs every 10 seconds and ManagerBase triggers a session
expiration check every 6 runs by default. So in short, they are checked
roughly every 60s. The test is pretty simple so it doesn't take very
long at all.
Or is there a smarter algorithm implemented there ?
Such as? I'm open to ideas here (maybe not for this exact problem but
certainly the general one).
Mark
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: control of session timed out with tomcat
Thanks for the clarification. Well, my system is like a ERP, what I want to do is basically: the user for work with the system, first must to be authenticated, then the user can works normally, then, if his session timed out, he need to relogin, that is the reason because I need to control the sessions, but what the user was doing before relogin, must be on hold, if the authentication is successful, then the request of the user is committed. Any advice will be welcome. Thanks. On Thu, Oct 20, 2011 at 10:52 AM, André Warnier a...@ice-sa.com wrote: Alejandro Soto wrote: Hi, thanks for your replies, These are the only ways I have to do it?, I was reading something about filters, but I think only works with user interaction. The basic issues are these : 1) Tomcat (probably) doesn't spend its time all the time scanning stored sessions to see if one has expired, and deleting it. What it does is : when a new request comes in, and that new request has a session-id in it, then Tomcat looks for this stored session. If it finds it, it checks if it has expired, and if so, it deletes it and does as if the session had not been there in the first place. 2) even assuming that Tomcat would find out, without user interaction, that a session has expired, and wanted to send something somewhere, where would it send it ? It is not certain that the browser of that user still has a connection open with the server. And even if there was such a connection open, and Tomcat sent something on it, the browser isn't waiting for anything, since it has not requested anything. I wouldn't be surprised if the browser got very confused then. That's why you always need the browser to send something, to have Tomcat react and search for the session, and send an answer. Personally, I think that by trying to do this (in whatever way), you set yourself up for all kinds of bizarre happenings and side-effects. What is the problem you are trying to solve ? --**--**- To unsubscribe, e-mail: users-unsubscribe@tomcat.**apache.orgusers-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org -- Alejandro Soto M. Cel: 705-63861
Re: [OT?] control of session timed out with tomcat
On Thu, 2011-10-20 at 16:35 +0100, Mark Thomas wrote:
On 20/10/2011 16:22, André Warnier wrote:
Hassan Schroeder wrote:
On Thu, Oct 20, 2011 at 7:52 AM, André Warnier a...@ice-sa.com wrote:
1) Tomcat (probably) doesn't spend its time all the time scanning stored
sessions to see if one has expired, and deleting it.
Actually, it does. That's what session listeners depend on.
So, for example, I can have a ShoppingCart with a method like
public void valueUnbound(HttpSessionBindingEvent httpsessionbindingevent)
{
empty(); /* remove reserved status from items */
}
If the session times out without the cart contents being purchased,
the cart returns any items it contains to inventory. Very handy :-)
You mean that if there are 500 sessions active, Tomcat spends its time
checking all of them repeatedly on the off-chance that one has expired ?
It is handled by the background processing thread. By default that
thread runs every 10 seconds and ManagerBase triggers a session
expiration check every 6 runs by default. So in short, they are checked
roughly every 60s. The test is pretty simple so it doesn't take very
long at all.
Or is there a smarter algorithm implemented there ?
Such as? I'm open to ideas here (maybe not for this exact problem but
certainly the general one).
Not necessarily claiming better but:
* find the oldest session
* go to sleep until it's ready to expire (since you know nothing
interesting will happen before then)
* wake up and expire sessions that need expiring
* repeat
Of course, this would require a dedicated thread. If the background
thread handles more tasks than just expiring sessions there's probably
not much gain in doing this approach. Or you could use the 'find oldest
session' value to compute how many work cycles to skip until the next
actual check. Is the complexity worth the savings in CPU cycles? Eh,
probably a wash. Could set a minimum threshold and only use the computed
value if it's greater than the threshold. Incorporate the computation as
part of the session scan.
But you did ask... :-)
Mark
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [OT?] control of session timed out with tomcat
On 20/10/2011 17:01, Tim Watts wrote:
On Thu, 2011-10-20 at 16:35 +0100, Mark Thomas wrote:
On 20/10/2011 16:22, André Warnier wrote:
Hassan Schroeder wrote:
On Thu, Oct 20, 2011 at 7:52 AM, André Warnier a...@ice-sa.com wrote:
1) Tomcat (probably) doesn't spend its time all the time scanning stored
sessions to see if one has expired, and deleting it.
Actually, it does. That's what session listeners depend on.
So, for example, I can have a ShoppingCart with a method like
public void valueUnbound(HttpSessionBindingEvent httpsessionbindingevent)
{
empty(); /* remove reserved status from items */
}
If the session times out without the cart contents being purchased,
the cart returns any items it contains to inventory. Very handy :-)
You mean that if there are 500 sessions active, Tomcat spends its time
checking all of them repeatedly on the off-chance that one has expired ?
It is handled by the background processing thread. By default that
thread runs every 10 seconds and ManagerBase triggers a session
expiration check every 6 runs by default. So in short, they are checked
roughly every 60s. The test is pretty simple so it doesn't take very
long at all.
Or is there a smarter algorithm implemented there ?
Such as? I'm open to ideas here (maybe not for this exact problem but
certainly the general one).
Not necessarily claiming better but:
* find the oldest session
This can change dynamically since application code can change the
session expiration time at any point.
* go to sleep until it's ready to expire (since you know nothing
interesting will happen before then)
* wake up and expire sessions that need expiring
* repeat
Of course, this would require a dedicated thread. If the background
thread handles more tasks than just expiring sessions there's probably
not much gain in doing this approach. Or you could use the 'find oldest
session' value to compute how many work cycles to skip until the next
actual check. Is the complexity worth the savings in CPU cycles? Eh,
probably a wash. Could set a minimum threshold and only use the computed
value if it's greater than the threshold. Incorporate the computation as
part of the session scan.
But you did ask... :-)
If session expiration time was constant, this would be fine.
Unfortunately, that is not the case.
Mark
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: control of session timed out with tomcat
On Thu, Oct 20, 2011 at 8:35 AM, Alejandro Soto smalejan...@gmail.com wrote: Well, my system is like a ERP, what I want to do is basically: the user for work with the system, first must to be authenticated, then the user can works normally, then, if his session timed out, he need to relogin, that is the reason because I need to control the sessions, but what the user was doing before relogin, must be on hold, if the authentication is successful, then the request of the user is committed. I think you would need to be a lot more precise about requirements, like what you mean by what the user was doing before relogin. But generally, if you have some kind of transaction-in-progress when the session times out -- what's the question? You'll have to save the transaction state somewhere and re-associate it with the user's new session after s/he logs in again. The details could vary wildly according to your specific requirements :-) FWIW, -- Hassan Schroeder hassan.schroe...@gmail.com http://about.me/hassanschroeder twitter: @hassan - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: control of session timed out with tomcat
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tim, On 10/20/2011 10:15 AM, Tim Watts wrote: I should also point out that this approach is somewhat kludgey because of the inherent latency problems when the session is close to expiration. But I don't know of a rock solid approach. You just have to have the timer pop sufficiently sooner than the session expiration -- for some value of sufficient. Perhaps later? If you make the call too soon, you'll tickle the session and start the 30-minute (or whatever) clock all over again. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6giCMACgkQ9CaO5/Lv0PCDFgCeIhcfq/pC2z8MNjGwmvNPCjBh qIAAoLq64F23ZnkcY1Lj6L/bqeO22CYp =HT9l -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [OT?] control of session timed out with tomcat
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mark, On 10/20/2011 11:35 AM, Mark Thomas wrote: On 20/10/2011 16:22, André Warnier wrote: Or is there a smarter algorithm implemented there ? Such as? I'm open to ideas here (maybe not for this exact problem but certainly the general one). I suppose one could use a (inverse?) priority queue where the priority is the last session touch time. When a session is touched, it's place in the queue is adjusted. When it's time to cull the sessions, you linearly process the queue until you hit a session that does not require expiration, and you're done. Use of a priority queue might end up being less efficient than the current implementation, especially when considering the cost of synchronization for shuffling sessions around in the queue (on every request!) and then getting an exclusive lock for the session-reaper which may last a non-trivial amount of time. I suspect session events are triggered directly by the background thread, and not delegated to another thread, so a long-running valueUnbound job could hold-up the entire container. I didn't say it was a good idea... only that is was AN idea :) - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6gieQACgkQ9CaO5/Lv0PBQ9ACeMVOxFI7tp5HnJ2QYM5R3X9y+ 6kYAnRZM2OUQqtMYrwTStrZLK5fPjJ7/ =LYNt -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: control of session timed out with tomcat
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Alejandro, On 10/20/2011 11:35 AM, Alejandro Soto wrote: Well, my system is like a ERP, what I want to do is basically: the user for work with the system, first must to be authenticated, then the user can works normally, then, if his session timed out, he need to relogin, that is the reason because I need to control the sessions, but what the user was doing before relogin, must be on hold, if the authentication is successful, then the request of the user is committed. Any advice will be welcome. Keep as much information in a form on the page as you can for long, possibly interruptable workflows. When you submit that form, if the session is dead, after re-authentication, the form submission will be replayed and the workflow can continue. We do this exact thing in pretty much all of our flows: each form submission has enough information to resume the flow even after a session expiration. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6giqIACgkQ9CaO5/Lv0PChagCePRzdvasTHVV4UEoq1psdWzEG auwAoJwIGB+WoVvDlZcpCPatIk4RHYxS =4Y80 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: control of session timed out with tomcat
On Thu, 2011-10-20 at 16:44 -0400, Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tim, On 10/20/2011 10:15 AM, Tim Watts wrote: I should also point out that this approach is somewhat kludgey because of the inherent latency problems when the session is close to expiration. But I don't know of a rock solid approach. You just have to have the timer pop sufficiently sooner than the session expiration -- for some value of sufficient. Perhaps later? If you make the call too soon, you'll tickle the session and start the 30-minute (or whatever) clock all over again. Ah. Left out an important piece of the puzzle: included an indicator on the redirect URL to invalidate the session. The reason for not doing it later was the whole point of the exercise in my case: The client (paycheck writer) didn't like submitting work and being surprised that their session had already expired. This was a while ago -- no HttpSessionListeners available -- so we couldn't easily persist the session and recall it when the user logged in again. As, I think, Andre was perhaps alluding to, this approach by itself is probably overlooking a deeper problem. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6giCMACgkQ9CaO5/Lv0PCDFgCeIhcfq/pC2z8MNjGwmvNPCjBh qIAAoLq64F23ZnkcY1Lj6L/bqeO22CYp =HT9l -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
