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, e-mail: [EMAIL PROTECTED]
