Re: cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session JDBCStore.java PersistentManagerBase.java StandardManager.java StandardSession.java StoreBase.java
Glenn Nielsen wrote: Remy, I am sick and tired of your crap. For whatever reason you don't like any of my contributions. You always try to find some way to justify a -1 of anything I contribute. Frankly you are the main reason why I rarely contribute to Tomcat any more. I just got tired of dealing with your shit. IMHO your interactions with people on this list and in bugzilla hurts the Tomcat community. I get the message. Frankly, I do not miss your contributions, as I have always considered to be of average quality. You're not the only one who hasn't appreciated working with the other. I'd like to point out that: - I do listen to feedback, so I have retracted my -1 - I don't see how you can expect to be well recieved if you make an unnanouced risky patch on a really mature branch after having been away from months Of course, I will reflect this in light of my involvement with the community. I think this can wait until the new release, which is a few days away. And of course I did discusss this patch before I committed it. I posted a summary of the patch on Apr 20 which contained the same information as my commit message. From anyone else I would expect an apology, but not from an egotistical piece of shit like you. I somehow did miss the original message, so I apologize. Really a bad mistake on my part, and I suggest using [PROPOSAL] to attract more attention, and esp when proposing core changes. Now, as for the rest of the paragraph, I obviously don't want to have to interact with you anymore. And for those of you watching from the sidelines this is the first time on any of the ASF/Tomcat lists I have attacked someone personally. I have always tried to keep discussions technical rather than get personal. Whatever. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session JDBCStore.java PersistentManagerBase.java StandardManager.java StandardSession.java StoreBase.java
On Sat, May 01, 2004 at 02:26:34PM +0200, Remy Maucherat wrote: Glenn Nielsen wrote: Remy, I am sick and tired of your crap. For whatever reason you don't like any of my contributions. You always try to find some way to justify a -1 of anything I contribute. Frankly you are the main reason why I rarely contribute to Tomcat any more. I just got tired of dealing with your shit. IMHO your interactions with people on this list and in bugzilla hurts the Tomcat community. I get the message. Frankly, I do not miss your contributions, as I have always considered to be of average quality. You're not the only one who hasn't appreciated working with the other. Thats your opinion. Others can judge based on the major contributions I have made. Such as implementing the Java Security Manager and the major jasaper refactoring I did which boosted performance 25-33%. I'd like to point out that: - I do listen to feedback, so I have retracted my -1 - I don't see how you can expect to be well recieved if you make an unnanouced risky patch on a really mature branch after having been away from months As is normal for any feedback from you on my contributions, you rarely provide any technical reason, you just make some characterization such as risky patch without stating any valid technical reason why. Considering that someone on the list immediately posted a message thanking me for fixing some problems they were having with Sessions and JDBCStore your knee-jerk reaction to -1 anything I contribute obviously hurts Tomcat. Of course, I will reflect this in light of my involvement with the community. I think this can wait until the new release, which is a few days away. And of course I did discusss this patch before I committed it. I posted a summary of the patch on Apr 20 which contained the same information as my commit message. From anyone else I would expect an apology, but not from an egotistical piece of shit like you. I somehow did miss the original message, so I apologize. Really a bad mistake on my part, and I suggest using [PROPOSAL] to attract more attention, and esp when proposing core changes. It was posted with [PATCH] on the subject line. Apology accepted. Now, as for the rest of the paragraph, I obviously don't want to have to interact with you anymore. I dont' care what you think of me personally. But when your animosity towards me impacts Tomcat I had to say something. Regards, Glenn -- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session JDBCStore.java PersistentManagerBase.java StandardManager.java StandardSession.java StoreBase.java
Glenn Nielsen wrote: I dont' care what you think of me personally. But when your animosity towards me impacts Tomcat I had to say something. I'm sure it fully justifies the egotistical piece of shit like you comment ;) Jon is funny at least, but this is just pathetic. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session JDBCStore.java PersistentManagerBase.java StandardManager.java StandardSession.java StoreBase.java
On Sat, May 01, 2004 at 06:39:15PM +0200, Remy Maucherat wrote: Glenn Nielsen wrote: I dont' care what you think of me personally. But when your animosity towards me impacts Tomcat I had to say something. I'm sure it fully justifies the egotistical piece of shit like you comment ;) Jon is funny at least, but this is just pathetic. Sometimes you have to jump on the table and rant a bit to grab peoples attention. I did go over the line with the statement you quoted above. Please accept my apology for that one. Glenn -- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session JDBCStore.java PersistentManagerBase.java StandardManager.java StandardSession.java StoreBase.java
Glenn Nielsen wrote: Please accept my apology for that one. Accepted. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session JDBCStore.java PersistentManagerBase.java StandardManager.java StandardSession.java StoreBase.java
glenn 2004/04/30 12:15:26
Modified:catalina/src/share/org/apache/catalina/session
JDBCStore.java PersistentManagerBase.java
StandardManager.java StandardSession.java
StoreBase.java
Log:
The JDBCStore required a great deal of unnecessary db
queries to manage the persisted data. This could severly
impact its ability to scale to large numbers of sessions.
1. When a JSESSIONID cookie was submitted with a request where
the Session no longer exists multiple queries of the db occurred
to try and load a persisted Session from the Store. I was
seeing four attempts to load from the persistence store
each request when a Session did not exist for a JSESSIONID.
PersistentManagerBase swapIn() and swapOut() were patched
to maintain a Hashtable of JSESSIONID's which do not exist
in the Store so that they don't have to be checked multiple
times. Each checkInterval the Hashtable is cleared to
prevent it from consuming too much memory.
2. The StoreBase.processExpires() method triggers a load of
each Session persisted to the db each checkInterval to
perform its test to determine if the Session has expired.
This incurred alot of overhead on the db, especially
if there was a large amount of session data. The number
of queries performed each checkInterval is 1 + number of
sessions persisted to the db + number of expired sessions
removed.
The StoreBase.processExpires() method was overridden
in JDBCStore. The method in JDBCStore performs a
query of the db to find only those Sessions which should
be expired. The number of queries performed here is 1 +
2 * the number of expired sessions (load then remove
of expired session).
3. JDBCStore.remove() is being called sometimes with a null
sessionid String causing an unnecessary synchronization
and db query.
Added a check for a null sessionid String at top of method.
Problems with expiring sessions have been reported numerous times.
The basic problem is as follows, starting at time 0 min and with
a max inactive interval of 30 minutes:
00 min: First request, new session created, LastAccessedTime 0
02 min: Second request, reuse session, LastAccessedTime 0
31 min: Third request, reuse session, LastAccessedTime now 2
33 min: Background manager thread expires session even though
it has only been two minutes since the remote clients
last request.
The argument for not changing how this works is based on how
the Servlet Spec defines Session.getLastAccessedTime().
But I agree with all those who have complained about this
behaviour that Tomcat session timeouts are buggy.
So I came up with a compromise that still allows the
HttpSession.getLastAccessedTime() to return the time of the
previous request for those who are Servlet Spec purists.
But internally sessions are expired when
current time last request + max inactive interval.
When we do a major revision we should consider adding
the StandardSession.getLastUsedTime() method to the
org.apache.catalina.Session interface.
Revision ChangesPath
1.13 +119 -5
jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session/JDBCStore.java
Index: JDBCStore.java
===
RCS file:
/home/cvs/jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session/JDBCStore.java,v
retrieving revision 1.12
retrieving revision 1.13
diff -u -r1.12 -r1.13
--- JDBCStore.java20 Mar 2004 10:57:18 - 1.12
+++ JDBCStore.java30 Apr 2004 19:15:26 - 1.13
@@ -201,6 +201,11 @@
*/
protected PreparedStatement preparedLoadSql = null;
+/**
+ * Variable to hold the codeprocessExpires()/code prepared statement.
+ */
+protected PreparedStatement preparedExpiresSql = null;
+
// - Properties
/**
@@ -630,6 +635,11 @@
* @exception IOException if an input/output error occurs
*/
public void remove(String id) throws IOException {
+
+if (id == null) {
+return;
+}
+
String removeSql =
DELETE FROM + sessionTable + WHERE + sessionIdCol +
= ? AND + sessionAppCol + = ?;
@@ -742,7 +752,7 @@
preparedSaveSql.setBinaryStream(3, in, size);
preparedSaveSql.setString(4, session.isValid()?1:0);
preparedSaveSql.setInt(5, session.getMaxInactiveInterval());
-preparedSaveSql.setLong(6, session.getLastAccessedTime());
+preparedSaveSql.setLong(6,
((StandardSession)session).getLastUsedTime());
preparedSaveSql.execute();
Re: cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session JDBCStore.java PersistentManagerBase.java StandardManager.java StandardSession.java StoreBase.java
[EMAIL PROTECTED] wrote: glenn 2004/04/30 12:15:26 Modified:catalina/src/share/org/apache/catalina/session JDBCStore.java PersistentManagerBase.java StandardManager.java StandardSession.java StoreBase.java Log: The JDBCStore required a great deal of unnecessary db queries to manage the persisted data. This could severly impact its ability to scale to large numbers of sessions. 1. When a JSESSIONID cookie was submitted with a request where the Session no longer exists multiple queries of the db occurred to try and load a persisted Session from the Store. I was seeing four attempts to load from the persistence store each request when a Session did not exist for a JSESSIONID. PersistentManagerBase swapIn() and swapOut() were patched to maintain a Hashtable of JSESSIONID's which do not exist in the Store so that they don't have to be checked multiple times. Each checkInterval the Hashtable is cleared to prevent it from consuming too much memory. 2. The StoreBase.processExpires() method triggers a load of each Session persisted to the db each checkInterval to perform its test to determine if the Session has expired. This incurred alot of overhead on the db, especially if there was a large amount of session data. The number of queries performed each checkInterval is 1 + number of sessions persisted to the db + number of expired sessions removed. The StoreBase.processExpires() method was overridden in JDBCStore. The method in JDBCStore performs a query of the db to find only those Sessions which should be expired. The number of queries performed here is 1 + 2 * the number of expired sessions (load then remove of expired session). 3. JDBCStore.remove() is being called sometimes with a null sessionid String causing an unnecessary synchronization and db query. Added a check for a null sessionid String at top of method. Problems with expiring sessions have been reported numerous times. The basic problem is as follows, starting at time 0 min and with a max inactive interval of 30 minutes: 00 min: First request, new session created, LastAccessedTime 0 02 min: Second request, reuse session, LastAccessedTime 0 31 min: Third request, reuse session, LastAccessedTime now 2 33 min: Background manager thread expires session even though it has only been two minutes since the remote clients last request. The argument for not changing how this works is based on how the Servlet Spec defines Session.getLastAccessedTime(). But I agree with all those who have complained about this behaviour that Tomcat session timeouts are buggy. So I came up with a compromise that still allows the HttpSession.getLastAccessedTime() to return the time of the previous request for those who are Servlet Spec purists. But internally sessions are expired when current time last request + max inactive interval. When we do a major revision we should consider adding the StandardSession.getLastUsedTime() method to the org.apache.catalina.Session interface. And of course you don't discuss this before making the change ? This is the old branch, so this is clearly not acceptable. I have to -1 regardless of the possible merits. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session JDBCStore.java PersistentManagerBase.java StandardManager.java StandardSession.java StoreBase.java
- Original Message - From: Remy Maucherat [EMAIL PROTECTED] And of course you don't discuss this before making the change ? This is the old branch, so this is clearly not acceptable. I have to -1 regardless of the possible merits. Ok, so he forgot to ask the developers if this would be ok, no big deal. Can happen to anybody. But if someone is fixing code and improving it, I don't think a -1 is fair just because you felt that you werent able to control the changes. If there is more to the story which would require the -1 to go into effect, you would need to share that. take-it-lightlyAfter all, we are not running a Boss/JBoss show here :)/take-it-lightly So if there is more to it, share is please, so that we can all know why this change is not reasonable. It is not the -1 that I am against, it is the lack of explanation to it. Filip - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session JDBCStore.java PersistentManagerBase.java StandardManager.java StandardSession.java StoreBase.java
Filip Hanik - Dev wrote: And of course you don't discuss this before making the change ? This is the old branch, so this is clearly not acceptable. I have to -1 regardless of the possible merits. Ok, so he forgot to ask the developers if this would be ok, no big deal. Can happen to anybody. But if someone is fixing code and improving it, I don't think a -1 is fair just because you felt that you werent able to control the changes. If there is more to the story which would require the -1 to go into effect, you would need to share that. take-it-lightlyAfter all, we are not running a Boss/JBoss show here :)/take-it-lightly I'm not very amused. Obviously the changes have nothing to do with JBoss. So if there is more to it, share is please, so that we can all know why this change is not reasonable. It is not the -1 that I am against, it is the lack of explanation to it. I consider the change is inappropriate for Tomcat 4.1.x. But actually, I really don't care anoymore about this branch, so make my vote a -0. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session JDBCStore.java PersistentManagerBase.java StandardManager.java StandardSession.java StoreBase.java
I'm just a list lurker (so my opinion doesn't count) but I'm really happy to see these fixes. I have had to override JDBCStore and PersistentManagerBase at my site to make similar fixes so that things work acceptably (yes, I submitted patches but they weren't accepted). Having these fixes in would allow me to upgrade to 4.1.x and get rid of my old overridden classes. Thanks Glenn! ~Tom On Apr 30, 2004, at 1:15 PM, [EMAIL PROTECTED] wrote: glenn 2004/04/30 12:15:26 Modified:catalina/src/share/org/apache/catalina/session JDBCStore.java PersistentManagerBase.java StandardManager.java StandardSession.java StoreBase.java Log: The JDBCStore required a great deal of unnecessary db queries to manage the persisted data. This could severly impact its ability to scale to large numbers of sessions. 1. When a JSESSIONID cookie was submitted with a request where the Session no longer exists multiple queries of the db occurred to try and load a persisted Session from the Store. I was seeing four attempts to load from the persistence store each request when a Session did not exist for a JSESSIONID. PersistentManagerBase swapIn() and swapOut() were patched to maintain a Hashtable of JSESSIONID's which do not exist in the Store so that they don't have to be checked multiple times. Each checkInterval the Hashtable is cleared to prevent it from consuming too much memory. 2. The StoreBase.processExpires() method triggers a load of each Session persisted to the db each checkInterval to perform its test to determine if the Session has expired. This incurred alot of overhead on the db, especially if there was a large amount of session data. The number of queries performed each checkInterval is 1 + number of sessions persisted to the db + number of expired sessions removed. The StoreBase.processExpires() method was overridden in JDBCStore. The method in JDBCStore performs a query of the db to find only those Sessions which should be expired. The number of queries performed here is 1 + 2 * the number of expired sessions (load then remove of expired session). 3. JDBCStore.remove() is being called sometimes with a null sessionid String causing an unnecessary synchronization and db query. Added a check for a null sessionid String at top of method. Problems with expiring sessions have been reported numerous times. The basic problem is as follows, starting at time 0 min and with a max inactive interval of 30 minutes: 00 min: First request, new session created, LastAccessedTime 0 02 min: Second request, reuse session, LastAccessedTime 0 31 min: Third request, reuse session, LastAccessedTime now 2 33 min: Background manager thread expires session even though it has only been two minutes since the remote clients last request. The argument for not changing how this works is based on how the Servlet Spec defines Session.getLastAccessedTime(). But I agree with all those who have complained about this behaviour that Tomcat session timeouts are buggy. So I came up with a compromise that still allows the HttpSession.getLastAccessedTime() to return the time of the previous request for those who are Servlet Spec purists. But internally sessions are expired when current time last request + max inactive interval. When we do a major revision we should consider adding the StandardSession.getLastUsedTime() method to the org.apache.catalina.Session interface. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session JDBCStore.java PersistentManagerBase.java StandardManager.java StandardSession.java StoreBase.java
Tom Anderson wrote: I'm just a list lurker (so my opinion doesn't count) but I'm really happy to see these fixes. I have had to override JDBCStore and PersistentManagerBase at my site to make similar fixes so that things work acceptably (yes, I submitted patches but they weren't accepted). Having these fixes in would allow me to upgrade to 4.1.x and get rid of my old overridden classes. The optimization part of the patch is useful. The session expiration fixes ae risky and change the API of some rather visible objects. The patch does not seem to cause any regressions, but obviously, there has been tons of examples where it looked to be the case, and problems occurred. So overall, I think the patch is too risky for that branch. But however, since I don't use it anymore, my opinion is not worth much. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session JDBCStore.java PersistentManagerBase.java StandardManager.java StandardSession.java StoreBase.java
On Fri, Apr 30, 2004 at 09:19:30PM +0200, Remy Maucherat wrote: [EMAIL PROTECTED] wrote: glenn 2004/04/30 12:15:26 Modified:catalina/src/share/org/apache/catalina/session JDBCStore.java PersistentManagerBase.java StandardManager.java StandardSession.java StoreBase.java Log: The JDBCStore required a great deal of unnecessary db queries to manage the persisted data. This could severly impact its ability to scale to large numbers of sessions. 1. When a JSESSIONID cookie was submitted with a request where the Session no longer exists multiple queries of the db occurred to try and load a persisted Session from the Store. I was seeing four attempts to load from the persistence store each request when a Session did not exist for a JSESSIONID. PersistentManagerBase swapIn() and swapOut() were patched to maintain a Hashtable of JSESSIONID's which do not exist in the Store so that they don't have to be checked multiple times. Each checkInterval the Hashtable is cleared to prevent it from consuming too much memory. 2. The StoreBase.processExpires() method triggers a load of each Session persisted to the db each checkInterval to perform its test to determine if the Session has expired. This incurred alot of overhead on the db, especially if there was a large amount of session data. The number of queries performed each checkInterval is 1 + number of sessions persisted to the db + number of expired sessions removed. The StoreBase.processExpires() method was overridden in JDBCStore. The method in JDBCStore performs a query of the db to find only those Sessions which should be expired. The number of queries performed here is 1 + 2 * the number of expired sessions (load then remove of expired session). 3. JDBCStore.remove() is being called sometimes with a null sessionid String causing an unnecessary synchronization and db query. Added a check for a null sessionid String at top of method. Problems with expiring sessions have been reported numerous times. The basic problem is as follows, starting at time 0 min and with a max inactive interval of 30 minutes: 00 min: First request, new session created, LastAccessedTime 0 02 min: Second request, reuse session, LastAccessedTime 0 31 min: Third request, reuse session, LastAccessedTime now 2 33 min: Background manager thread expires session even though it has only been two minutes since the remote clients last request. The argument for not changing how this works is based on how the Servlet Spec defines Session.getLastAccessedTime(). But I agree with all those who have complained about this behaviour that Tomcat session timeouts are buggy. So I came up with a compromise that still allows the HttpSession.getLastAccessedTime() to return the time of the previous request for those who are Servlet Spec purists. But internally sessions are expired when current time last request + max inactive interval. When we do a major revision we should consider adding the StandardSession.getLastUsedTime() method to the org.apache.catalina.Session interface. And of course you don't discuss this before making the change ? This is the old branch, so this is clearly not acceptable. I have to -1 regardless of the possible merits. Rémy Remy, I am sick and tired of your crap. For whatever reason you don't like any of my contributions. You always try to find some way to justify a -1 of anything I contribute. Frankly you are the main reason why I rarely contribute to Tomcat any more. I just got tired of dealing with your shit. IMHO your interactions with people on this list and in bugzilla hurts the Tomcat community. And of course I did discusss this patch before I committed it. I posted a summary of the patch on Apr 20 which contained the same information as my commit message. From anyone else I would expect an apology, but not from an egotistical piece of shit like you. And for those of you watching from the sidelines this is the first time on any of the ASF/Tomcat lists I have attacked someone personally. I have always tried to keep discussions technical rather than get personal. My warmest regards, Glenn -- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands,
Re: cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session JDBCStore.java PersistentManagerBase.java StandardManager.java StandardSession.java StoreBase.java
Thanks for the words of encouragement. Glenn On Fri, Apr 30, 2004 at 03:27:00PM -0600, Tom Anderson wrote: I'm just a list lurker (so my opinion doesn't count) but I'm really happy to see these fixes. I have had to override JDBCStore and PersistentManagerBase at my site to make similar fixes so that things work acceptably (yes, I submitted patches but they weren't accepted). Having these fixes in would allow me to upgrade to 4.1.x and get rid of my old overridden classes. Thanks Glenn! ~Tom On Apr 30, 2004, at 1:15 PM, [EMAIL PROTECTED] wrote: glenn 2004/04/30 12:15:26 Modified:catalina/src/share/org/apache/catalina/session JDBCStore.java PersistentManagerBase.java StandardManager.java StandardSession.java StoreBase.java Log: The JDBCStore required a great deal of unnecessary db queries to manage the persisted data. This could severly impact its ability to scale to large numbers of sessions. 1. When a JSESSIONID cookie was submitted with a request where the Session no longer exists multiple queries of the db occurred to try and load a persisted Session from the Store. I was seeing four attempts to load from the persistence store each request when a Session did not exist for a JSESSIONID. PersistentManagerBase swapIn() and swapOut() were patched to maintain a Hashtable of JSESSIONID's which do not exist in the Store so that they don't have to be checked multiple times. Each checkInterval the Hashtable is cleared to prevent it from consuming too much memory. 2. The StoreBase.processExpires() method triggers a load of each Session persisted to the db each checkInterval to perform its test to determine if the Session has expired. This incurred alot of overhead on the db, especially if there was a large amount of session data. The number of queries performed each checkInterval is 1 + number of sessions persisted to the db + number of expired sessions removed. The StoreBase.processExpires() method was overridden in JDBCStore. The method in JDBCStore performs a query of the db to find only those Sessions which should be expired. The number of queries performed here is 1 + 2 * the number of expired sessions (load then remove of expired session). 3. JDBCStore.remove() is being called sometimes with a null sessionid String causing an unnecessary synchronization and db query. Added a check for a null sessionid String at top of method. Problems with expiring sessions have been reported numerous times. The basic problem is as follows, starting at time 0 min and with a max inactive interval of 30 minutes: 00 min: First request, new session created, LastAccessedTime 0 02 min: Second request, reuse session, LastAccessedTime 0 31 min: Third request, reuse session, LastAccessedTime now 2 33 min: Background manager thread expires session even though it has only been two minutes since the remote clients last request. The argument for not changing how this works is based on how the Servlet Spec defines Session.getLastAccessedTime(). But I agree with all those who have complained about this behaviour that Tomcat session timeouts are buggy. So I came up with a compromise that still allows the HttpSession.getLastAccessedTime() to return the time of the previous request for those who are Servlet Spec purists. But internally sessions are expired when current time last request + max inactive interval. When we do a major revision we should consider adding the StandardSession.getLastUsedTime() method to the org.apache.catalina.Session interface. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder| MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
