Re: Session timeout related fixes between Tomcat 5.0 and Tomcat 5.5.x?
andre John Mas wrote:
Hi,
We are currently experiencing session issues with our customer's
Tomcat server, in a production environment. Basically what is
happening is that, despite the idle time-out being set for 20 minutes
we are seeing sessions that have been idle (have not been accessed)
for over 3 hours. The net result is that the Tomcat server needs to
get restarted.
We are currently investigating the reason why, but are currently in
the dark on how we should continue our analysis. If anyone has any
ideas they would be much appreciated.
There is a race condition when Tomcat 5.0 maintains the accessCount
attribute of a session, see
https://issues.apache.org/bugzilla/show_bug.cgi?id=37356
Tomcat does not invalidate sessions after session-timeout period has
passed.
This bug is fixed in Tomcat 5.5 and 6. We have seen it causing sessions
to hang around forever in production servers.
Furthermore there is a concurrency bug accessing the session attributes:
https://issues.apache.org/bugzilla/show_bug.cgi?id=36541
session getAttribute/setAttribute and removeAttribute are NOT Thread
safe.
Both are fixed in the patch below for Tomcat 5.0
Regards,
Oliver Schoett
---
dist/jakarta-tomcat-5.0.25-src/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/session/StandardSession.java
2004-05-17 20:10:50.0 +0200
+++
jakarta-tomcat-5.0.25-src/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/session/StandardSession.java
2008-09-25 14:53:15.046667200 +0200
@@ -31,6 +31,8 @@
import java.util.ArrayList;
import java.util.Enumeration;
import java.util.HashMap;
+import java.util.Map;
+import java.util.concurrent.ConcurrentHashMap;
import java.util.Iterator;
import javax.servlet.ServletContext;
@@ -116,7 +118,7 @@
/**
* The collection of user data attributes associated with this Session.
*/
-protected HashMap attributes = new HashMap();
+protected Map attributes = new ConcurrentHashMap();
/**
@@ -280,6 +282,11 @@
*/
protected transient int accessCount = 0;
+/**
+ * Object used to synchronize accesses to accessCount
+ */
+private final transient Object accessCountLock = new Object();
+
// - Session Properties
@@ -555,8 +562,10 @@
return false;
}
-if (accessCount 0) {
-return true;
+synchronized (accessCountLock) {
+if (accessCount 0) {
+return true;
+}
}
if (maxInactiveInterval= 0) {
@@ -597,7 +606,9 @@
evaluateIfValid();
-accessCount++;
+synchronized (accessCountLock) {
+accessCount++;
+}
}
@@ -608,7 +619,9 @@
public void endAccess() {
isNew = false;
-accessCount--;
+synchronized (accessCountLock) {
+accessCount--;
+}
}
@@ -687,7 +700,9 @@
}
}
}
-accessCount = 0;
+synchronized (accessCountLock) {
+accessCount = 0;
+}
setValid(false);
// Remove this session from our manager's active sessions
@@ -802,7 +817,9 @@
id = null;
lastAccessedTime = 0L;
maxInactiveInterval = -1;
-accessCount = 0;
+synchronized (accessCountLock) {
+accessCount = 0;
+}
notes.clear();
setPrincipal(null);
isNew = false;
@@ -1329,7 +1346,7 @@
// Deserialize the attribute count and attribute values
if (attributes == null)
-attributes = new HashMap();
+attributes = new ConcurrentHashMap();
int n = ((Integer) stream.readObject()).intValue();
boolean isValidSave = isValid;
isValid = true;
@@ -1341,9 +1358,9 @@
if (debug= 2)
log( loading attribute ' + name +
' with value ' + value + ');
-synchronized (attributes) {
+// OS no longer needed: synchronized (attributes) {
attributes.put(name, value);
-}
+// OS no longer needed: }
}
isValid = isValidSave;
@@ -1388,9 +1405,9 @@
ArrayList saveValues = new ArrayList();
for (int i = 0; i keys.length; i++) {
Object value = null;
-synchronized (attributes) {
+// OS no longer needed: synchronized (attributes) {
value = attributes.get(keys[i]);
-}
+// OS no longer needed: }
if (value == null)
continue;
else if ( (value instanceof Serializable)
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Session timeout related fixes between Tomcat 5.0 and Tomcat 5.5.x?
Hi,
We are using tomcat 5.5.25. Seems the same issue is there. Its been fixed in
that version 5.5.25?
And how could we configure tomcat 5.5.25 to load jsp pages faster??
Regards, Kranti.
On Fri, Dec 5, 2008 at 4:50 PM, Oliver Schoett
[EMAIL PROTECTED] wrote:
andre John Mas wrote:
Hi,
We are currently experiencing session issues with our customer's Tomcat
server, in a production environment. Basically what is happening is that,
despite the idle time-out being set for 20 minutes we are seeing sessions
that have been idle (have not been accessed) for over 3 hours. The net
result is that the Tomcat server needs to get restarted.
We are currently investigating the reason why, but are currently in the
dark on how we should continue our analysis. If anyone has any ideas they
would be much appreciated.
There is a race condition when Tomcat 5.0 maintains the accessCount
attribute of a session, see
https://issues.apache.org/bugzilla/show_bug.cgi?id=37356
Tomcat does not invalidate sessions after session-timeout period has
passed.
This bug is fixed in Tomcat 5.5 and 6. We have seen it causing sessions to
hang around forever in production servers.
Furthermore there is a concurrency bug accessing the session attributes:
https://issues.apache.org/bugzilla/show_bug.cgi?id=36541
session getAttribute/setAttribute and removeAttribute are NOT Thread
safe.
Both are fixed in the patch below for Tomcat 5.0
Regards,
Oliver Schoett
---
dist/jakarta-tomcat-5.0.25-src/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/session/StandardSession.java
2004-05-17 20:10:50.0 +0200
+++
jakarta-tomcat-5.0.25-src/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/session/StandardSession.java
2008-09-25 14:53:15.046667200 +0200
@@ -31,6 +31,8 @@
import java.util.ArrayList;
import java.util.Enumeration;
import java.util.HashMap;
+import java.util.Map;
+import java.util.concurrent.ConcurrentHashMap;
import java.util.Iterator;
import javax.servlet.ServletContext;
@@ -116,7 +118,7 @@
/**
* The collection of user data attributes associated with this Session.
*/
-protected HashMap attributes = new HashMap();
+protected Map attributes = new ConcurrentHashMap();
/**
@@ -280,6 +282,11 @@
*/
protected transient int accessCount = 0;
+/**
+ * Object used to synchronize accesses to accessCount
+ */
+private final transient Object accessCountLock = new Object();
+
// - Session
Properties
@@ -555,8 +562,10 @@
return false;
}
-if (accessCount 0) {
-return true;
+synchronized (accessCountLock) {
+if (accessCount 0) {
+return true;
+}
}
if (maxInactiveInterval= 0) {
@@ -597,7 +606,9 @@
evaluateIfValid();
-accessCount++;
+synchronized (accessCountLock) {
+accessCount++;
+}
}
@@ -608,7 +619,9 @@
public void endAccess() {
isNew = false;
-accessCount--;
+synchronized (accessCountLock) {
+accessCount--;
+}
}
@@ -687,7 +700,9 @@
}
}
}
-accessCount = 0;
+synchronized (accessCountLock) {
+accessCount = 0;
+}
setValid(false);
// Remove this session from our manager's active sessions
@@ -802,7 +817,9 @@
id = null;
lastAccessedTime = 0L;
maxInactiveInterval = -1;
-accessCount = 0;
+synchronized (accessCountLock) {
+accessCount = 0;
+}
notes.clear();
setPrincipal(null);
isNew = false;
@@ -1329,7 +1346,7 @@
// Deserialize the attribute count and attribute values
if (attributes == null)
-attributes = new HashMap();
+attributes = new ConcurrentHashMap();
int n = ((Integer) stream.readObject()).intValue();
boolean isValidSave = isValid;
isValid = true;
@@ -1341,9 +1358,9 @@
if (debug= 2)
log( loading attribute ' + name +
' with value ' + value + ');
-synchronized (attributes) {
+// OS no longer needed: synchronized (attributes) {
attributes.put(name, value);
-}
+// OS no longer needed: }
}
isValid = isValidSave;
@@ -1388,9 +1405,9 @@
ArrayList saveValues = new ArrayList();
for (int i = 0; i keys.length; i++) {
Object value = null;
-synchronized (attributes) {
+// OS no longer needed: synchronized (attributes) {
value = attributes.get(keys[i]);
-}
+// OS no longer
RE: Session timeout related fixes between Tomcat 5.0 and Tomcat 5.5.x?
From: Caldarale, Charles R [EMAIL PROTECTED] To: Tomcat Users List users@tomcat.apache.org Subject: RE: Session timeout related fixes between Tomcat 5.0 and Tomcat 5.5.x? From: andre John Mas [mailto:[EMAIL PROTECTED] Subject: Session timeout related fixes between Tomcat 5.0 and Tomcat 5.5.x? Basically what is happening is that, despite the idle time-out being set for 20 minutes we are seeing sessions that have been idle (have not been accessed) for over 3 hours. Do you have keep alives enabled? Look at the maxKeepAliveRequests attribute: http://tomcat.apache.org/tomcat-5.5-doc/config/http.html#Standard%20Implementation Is your webapp caching sessions for any reason? Can you implement a SessionListener to see if expiration events are occurring? The net result is that the Tomcat server needs to get restarted. Why? Are you running out of heap space? Do you have a memory leak elsewhere as well? One parallel line of analysis is to find out if there were any fixes between 5.0.x and 5.5.x, that are related to sessions not timing out. The changelog is here for your perusal: http://tomcat.apache.org/tomcat-5.5-doc/changelog.html I have implemented a session listener and also activated access logs. The session listener adds a list with sessionCreated() and removes them with sessionDestroyed(). I then have a JSP that displays the list, along with when the session was created, using getCreationTime(), and when the session was last accessed, using getLastAccessedTime(). If a session has already been invalidated by the container I will get a IllegalStateException when I call getCreationTime() on the session I am getting the information from. An example output of my tool is: sessioninfo count=581 maxLife=657.410 maxIdle=636.710 session id=54D57E020A2791CDDDE6307E7565C328 life=657.410 idle=632.789 / session id=6EE000B43250CC6CEDCD3B2D95A5A79B life=657.039 idle=616.064 / session id=8CE0C68E1098C291D69F70FEB4EFC631 life=641.774 idle=636.710 / session id=10C182293F0CBA68291AF2C439E6058A life=104.579 idle=65.900 / session id=F62A60B0037D09D44B7F27E549A4D6B1 life=104.336 idle=74.971 / session id=CAC0CA3066737D8316CBABB7E960EDBC life=104.195 idle=98.052 / session id=FD8CCFF63428DE1C50A668DF27C2865D life=103.911 idle=64.812 / session id=874032F034F3E12C911C9152632C5D7D life=101.407 idle=99.031 / /sessioninfo - life is current time - creation time. - idle is current time - last accessed time. When I speak to our operations team they tell me that the server crashes because it is unable to create any more sessions, so it is possible we are out of heap space. The logs show me that at least half of the sessions are idle for more than 30min. I could probably add more information to the tool to display memory usage. The other issue is that we are having trouble reproducing this in a development environment, so it is making our life just a bit harder. The changelog that you pointed me to only seems to cover changes from 5.5 onwards. There is nothing there covering 5.x previous to that. Are there any older logs available anywhere? Andre - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Session timeout related fixes between Tomcat 5.0 and Tomcat 5.5.x?
From: andre John Mas [mailto:[EMAIL PROTECTED] Subject: RE: Session timeout related fixes between Tomcat 5.0 and Tomcat 5.5.x? When I speak to our operations team they tell me that the server crashes because it is unable to create any more sessions They're fudging, so you really do need to find out what the exact problem is. I then have a JSP that displays the list You should also capture the timeout value for each session via getMaxInactiveInterval() to see if your webapp is changing the setting from the default. The other issue is that we are having trouble reproducing this in a development environment I presume that means sessions are behaving themselves and going away after 30 minutes. The changelog that you pointed me to only seems to cover changes from 5.5 onwards. Which is what you asked for; 5.5.0 was cut from whatever the 5.0 version was at the time. (There were no 5.1 - 5.4 legs.) All code that went into 5.5 is described there, although possibly not as comprehensively as we'd like. - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
