DO NOT REPLY [Bug 36541] - session getAttribute/setAttribute and removeAttribute are NOT Thread safe.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36541. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36541 --- Additional Comments From [EMAIL PROTECTED] 2005-09-08 08:50 --- (In reply to comment #20) As discussed on tomcat-dev after I reexamined StandardSession code further, adequate synchrnoization seems to be in place in the current Tomcat 5.5 code so that the infinite loop situation described in this issue does not occur. Please do not reopen the report. Remy, sorry, but you are wrong. The read is the problem, not the write. During the write process the hashmap is in flux, so if a read occurs at this time and is not synchronized the thread which reads is killed. So 5.5.x is as broken as 5.0.x is -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36113] - Session persistence for objects with primitive types
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36113. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36113 --- Additional Comments From [EMAIL PROTECTED] 2005-09-08 10:32 --- Hi, I tried to reproduce the problem using a simple program but I did fail (boolean seems to get converted to java.lang.Boolean in any case I tried). The problem is occurring using a third party library and I am not sure what these guys are doing to contain primitive types in the session. This application does not work without a very big environment, so it is not possible for me to provide a war to test the behaviour. The proble also occurs in Replication, where the same bug exists. See the stack trace (from 5.5.9, builtin in JBoss): 08.09.2005 09:46:59.724 titan ERROR - ClassNotFoundException while loading persisted sessions: java.lang.ClassNotFoundException: boolean java.lang.ClassNotFoundException: boolean at org.apache.catalina.loader.WebappClassLoader.loadClass (WebappClassLoader.java:1332) at org.apache.catalina.loader.WebappClassLoader.loadClass (WebappClassLoader.java:1181) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:242) at org.apache.catalina.util.CustomObjectInputStream.resolveClass (CustomObjectInputStream.java:73) at java.io.ObjectInputStream.readNonProxyDesc (ObjectInputStream.java:1538) at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1460) at java.io.ObjectInputStream.readClass(ObjectInputStream.java:1427) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1282) at java.io.ObjectInputStream.defaultReadFields (ObjectInputStream.java:1912) at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1836) at java.io.ObjectInputStream.readOrdinaryObject (ObjectInputStream.java:1713) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1299) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:339) at java.util.LinkedList.readObject(LinkedList.java:776) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at java.io.ObjectStreamClass.invokeReadObject (ObjectStreamClass.java:919) at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1813) at java.io.ObjectInputStream.readOrdinaryObject (ObjectInputStream.java:1713) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1299) at java.io.ObjectInputStream.defaultReadFields (ObjectInputStream.java:1912) at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1836) at java.io.ObjectInputStream.readOrdinaryObject (ObjectInputStream.java:1713) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1299) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:339) at java.util.ArrayList.readObject(ArrayList.java:587) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at java.io.ObjectStreamClass.invokeReadObject (ObjectStreamClass.java:919) at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1813) at java.io.ObjectInputStream.readOrdinaryObject (ObjectInputStream.java:1713) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1299) at java.io.ObjectInputStream.defaultReadFields (ObjectInputStream.java:1912) at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1836) at java.io.ObjectInputStream.readOrdinaryObject (ObjectInputStream.java:1713) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1299) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:339) at java.util.ArrayList.readObject(ArrayList.java:587) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at java.io.ObjectStreamClass.invokeReadObject
DO NOT REPLY [Bug 36541] - session getAttribute/setAttribute and removeAttribute are NOT Thread safe.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=36541.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=36541
--- Additional Comments From [EMAIL PROTECTED] 2005-09-08 11:01 ---
Hmm, I also thing the spec interpretation from the current
StandardSession inside Tomcat 5.0 and 5.5. is wrong. We had the same problem
at Cluster DeltaSession for year ago. We now sync also the session attribute
read operations. Without this fix the Cluster setup is useless for
production servers.
I vote for change the StandardSession implementation to..
public Object getAttribute(String name) {
if (!isValid())
throw new IllegalStateException(sm
.getString(standardSession.getAttribute.ise));
synchronized (attributes) {
return (attributes.get(name));
}
}
public Enumeration getAttributeNames() {
if (!isValid())
throw new IllegalStateException(sm
.getString(standardSession.getAttributeNames.ise));
synchronized (attributes) {
return (new Enumerator(attributes.keySet(), true));
}
}
===
Peter
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36541] - session getAttribute/setAttribute and removeAttribute are NOT Thread safe.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36541. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36541 --- Additional Comments From [EMAIL PROTECTED] 2005-09-08 11:35 --- Created an attachment (id=16339) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=16339action=view) compiled fix for 5.0.25 a compiled patch for 5.0.19+ -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36541] - session getAttribute/setAttribute and removeAttribute are NOT Thread safe.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36541. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36541 --- Additional Comments From [EMAIL PROTECTED] 2005-09-08 11:36 --- Created an attachment (id=16340) -- (http://issues.apache.org/bugzilla/attachment.cgi?id=16340action=view) patch for 5.0.19+, source code patch for 5.0.19+, source code -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36541] - session getAttribute/setAttribute and removeAttribute are NOT Thread safe.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36541. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36541 --- Additional Comments From [EMAIL PROTECTED] 2005-09-08 11:42 --- I submitted a patch for 5.0.19+. To install it: jar -xf catalina.jar replace StandardSession.class with one attached. make a new jar. Alternatively you can rebuild complete tomcat, so i supplied the source code too :-) It would be cool to provide a download location for the patched catalina.jar, i don't think submitting a 700K file into bugzilla is the correct behaviour, so I'm not doing it. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36541] - session getAttribute/setAttribute and removeAttribute are NOT Thread safe.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36541. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36541 --- Additional Comments From [EMAIL PROTECTED] 2005-09-08 12:23 --- (In reply to comment #24) Hmm, I also thing the spec interpretation from the current StandardSession inside Tomcat 5.0 and 5.5. is wrong. We had the same problem at Cluster DeltaSession for year ago. We now sync also the session attribute read operations. Without this fix the Cluster setup is useless for production servers. I vote for change the StandardSession implementation to.. Ok. I don't know yet, since the repository is inconclusive, and doesn't match what you wrote. I see DeltaSession (introduced first along with 5.0.15+) has always had (from revision 1.1) syncs on everything (read/writes), so I don't see any conclusive information showing that the current 5.5.x code does produce the bug described here. Obviously, if 5.5.x really is still bad for this issue, it'll have to be fixed. (In reply to comment #23) Remy, sorry, but you are wrong. The read is the problem, not the write. During the write process the hashmap is in flux, so if a read occurs at this time and is not synchronized the thread which reads is killed. So 5.5.x is as broken as 5.0.x is This means you've tested with 5.5.x, and reproduced an issue ? Or written a microbenchmark showing a problem with reads ? All I can see is that you're saying issue on read, 5.5.x same problem like a broken record. (In reply to comment #22) Apparently it is indeed a good thing :-). The appropriate patch was just committed to the Glassfish repository. If people want an open source implementation of the servlet spec where the developers listen to users on issues like this, you might want to browse over to: https://glassfish.dev.java.net and take a look. Lol, whatever. The web tier of Glassfish is really an ugly behind-the-back fork. All that was required to avoid the ill feelings is a bit of respect, being informed just a little bit, which would have allowed reasonable planning for development resources. I'm glad you're happy about Glassfish, but personally, I'll use it in the long run to point out there are problems with large companies like Sun and IBM, their interactions with the ASF, and how they should not be trusted (as in, accept whatever they contribute, but there's no need for being thankful for it - and obviously, don't install them as despot on a project ever, but at the ASF, it's a bit hard to get into this situation). This (removing my name from the @author tag on StandardSession), both here and everywhere else in the Tomcat code base, would indeed be my wish. I wasn't really serious. In the end, it's not really my decision, so you should send a request to the pmc once it is correctly setup. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36541] - session getAttribute/setAttribute and removeAttribute are NOT Thread safe.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36541. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36541 --- Additional Comments From [EMAIL PROTECTED] 2005-09-08 12:26 --- It should be posssible to install such patches by simply place the class file at the correct position. In this case it would be jakarta-tomcat-5.0.28/server/classes/org/apache/catalina/session -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36541] - session getAttribute/setAttribute and removeAttribute are NOT Thread safe.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36541. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36541 --- Additional Comments From [EMAIL PROTECTED] 2005-09-08 12:34 --- (In reply to comment #29) It should be posssible to install such patches by simply place the class file at the correct position. In this case it would be jakarta-tomcat-5.0.28/server/classes/org/apache/catalina/session Yes, the classloader setup has been designed to easily allow such patching, but the folder structure can get a bit messy (you got it right, though). -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml
remm2005/09/08 03:45:14
Modified:catalina/src/share/org/apache/naming/resources
DirContextURLStreamHandler.java
catalina/src/share/org/apache/catalina/core
ApplicationContext.java
webapps/docs changelog.xml
Log:
- 36534: Context relative URLs returned by ServletContext.getResource() for
the same path are not equal.
- Jan's patch.
Revision ChangesPath
1.4 +36 -1
jakarta-tomcat-catalina/catalina/src/share/org/apache/naming/resources/DirContextURLStreamHandler.java
Index: DirContextURLStreamHandler.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/naming/resources/DirContextURLStreamHandler.java,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -r1.3 -r1.4
--- DirContextURLStreamHandler.java 27 Feb 2004 14:58:54 - 1.3
+++ DirContextURLStreamHandler.java 8 Sep 2005 10:45:13 - 1.4
@@ -89,6 +89,41 @@
}
+// URL
Methods
+
+
+/**
+ * Override as part of the fix for 36534, to ensure toString is correct.
+ */
+protected String toExternalForm(URL u) {
+// pre-compute length of StringBuffer
+int len = u.getProtocol().length() + 1;
+if (u.getPath() != null) {
+len += u.getPath().length();
+}
+if (u.getQuery() != null) {
+len += 1 + u.getQuery().length();
+}
+if (u.getRef() != null)
+len += 1 + u.getRef().length();
+StringBuffer result = new StringBuffer(len);
+result.append(u.getProtocol());
+result.append(:);
+if (u.getPath() != null) {
+result.append(u.getPath());
+}
+if (u.getQuery() != null) {
+result.append('?');
+result.append(u.getQuery());
+}
+if (u.getRef() != null) {
+result.append(#);
+result.append(u.getRef());
+}
+return result.toString();
+}
+
+
// - Public
Methods
1.30 +2 -2
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/ApplicationContext.java
Index: ApplicationContext.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/core/ApplicationContext.java,v
retrieving revision 1.29
retrieving revision 1.30
diff -u -r1.29 -r1.30
--- ApplicationContext.java 29 Aug 2005 10:38:38 - 1.29
+++ ApplicationContext.java 8 Sep 2005 10:45:14 - 1.30
@@ -497,7 +497,7 @@
try {
resources.lookup(path);
return new URL
-(jndi, null, 0, getJNDIUri(hostName, fullPath),
+(jndi, , 0, getJNDIUri(hostName, fullPath),
new DirContextURLStreamHandler(resources));
} catch (Exception e) {
// Ignore
1.369 +4 -1 jakarta-tomcat-catalina/webapps/docs/changelog.xml
Index: changelog.xml
===
RCS file: /home/cvs/jakarta-tomcat-catalina/webapps/docs/changelog.xml,v
retrieving revision 1.368
retrieving revision 1.369
diff -u -r1.368 -r1.369
--- changelog.xml 6 Sep 2005 12:50:55 - 1.368
+++ changelog.xml 8 Sep 2005 10:45:14 - 1.369
@@ -33,7 +33,7 @@
Remove uneeded files in conf. (remm)
/fix
update
-Change distribution file names from jakarta-* to apache-*.
+Change distribution file names from jakarta-* to apache-*. (remm)
/update
/changelog
/subsection
@@ -49,6 +49,9 @@
add
bug36088/bug: Add RUNNING.txt and RELEASE-NOTES.txt to fulldocs
distro. (yoavs)
/add
+ fix
+bug36534/bug: fix equals for URLs returned by
ServletContext.getResource() (luehe)
+ /fix
/changelog
/subsection
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36113] - Session persistence for objects with primitive types
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=36113.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=36113
[EMAIL PROTECTED] changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|WORKSFORME |
--- Additional Comments From [EMAIL PROTECTED] 2005-09-08 13:27 ---
(In reply to comment #4)
Hi, I tried to reproduce the problem using a simple program but I did fail
(boolean seems to get converted to java.lang.Boolean in any case I tried).
The problem is occurring using a third party library and I am not sure what
these guys are doing to contain primitive types in the session. This
application does not work without a very big environment, so it is not
possible
for me to provide a war to test the behaviour.
The proble also occurs in Replication, where the same bug exists.
Ok, I understand (to some extent: it's weird). One of the issues is that I don't
feel confident cut pasting Sun's code.
Can you test to see if this change works fine with your webapp:
public Class resolveClass(ObjectStreamClass classDesc)
throws ClassNotFoundException, IOException {
try {
return Class.forName(classDesc.getName(), false, classLoader);
} catch (ClassNotFoundException e) {
return super.resolveClass(classDesc);
}
}
?
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36541] - session getAttribute/setAttribute and removeAttribute are NOT Thread safe.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36541. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36541 --- Additional Comments From [EMAIL PROTECTED] 2005-09-08 13:48 --- (In reply to comment #28) This means you've tested with 5.5.x, and reproduced an issue ? Or written a microbenchmark showing a problem with reads ? All I can see is that you're saying issue on read, 5.5.x same problem like a broken record. No this means that the statement of the HashMap authors: * pbNote that this implementation is not synchronized./b If multiple * threads access this map concurrently, and at least one of the threads * modifies the map structurally, it imust/i be synchronized externally. also applies to x Reader, one Writer, so synchronizing writes only is a misusage of the HashMap according to the documentation. On the other hand, I made some measures and calculated how much performance you gain by removing synchronization from get/set methods. I compared the performance of synchronized hashmap access against not synchronized (singlethreaded, pIV 2.8 Ghz, HT) and calculated that you gain 230 milliseconds on 3,000,000 operations! That is 0.8 milliseconds per operation. Even you would have 100 accesses to the session from 100 parallel threads, it would cost you additional 8 milliseconds. According to alexa.com we have an average response time of 0.8 seconds (for the user) and are faster then 80% of the net (google's average is 0.7). I don't know how many sites are faster, lets assume the fastest are at about 0.5 seconds (and sites making 100 session accesses in one request surely do not belong in this category). So if your average request duration is 500 millis, how important is it for you to gain 0.8 milliseconds, or even 0.8 milliseconds? -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36541] - session getAttribute/setAttribute and removeAttribute are NOT Thread safe.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36541. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36541 --- Additional Comments From [EMAIL PROTECTED] 2005-09-08 14:08 --- (In reply to comment #31) No this means that the statement of the HashMap authors: * pbNote that this implementation is not synchronized./b If multiple * threads access this map concurrently, and at least one of the threads * modifies the map structurally, it imust/i be synchronized externally. also applies to x Reader, one Writer, so synchronizing writes only is a misusage of the HashMap according to the documentation. It's cool, but I have not asked for the nth lecture of this portion of the javadoc. How about trying to answer my question ? It doesn't seem that hard. On the other hand, I made some measures and calculated how much performance you gain by removing synchronization from get/set methods. I compared the performance of synchronized hashmap access against not synchronized (singlethreaded, pIV 2.8 Ghz, HT) and calculated that you gain 230 milliseconds on 3,000,000 operations! That is 0.8 milliseconds per operation. Even you would have 100 accesses to the session from 100 parallel threads, it would cost you additional 8 milliseconds. According to alexa.com we have an average response time of 0.8 seconds (for the user) and are faster then 80% of the net (google's average is 0.7). I don't know how many sites are faster, lets assume the fastest are at about 0.5 seconds (and sites making 100 session accesses in one request surely do not belong in this category). So if your average request duration is 500 millis, how important is it for you to gain 0.8 milliseconds, or even 0.8 milliseconds? In a microbenchmark, the JIT could be playing tricks on you, so I don't know ;) Obviously, one single read by itself is not going to cost much. Now multiply that by the number of reads you could be making during a single request, and also imagine what it could be if useless syncs were added in plenty other places inside the container just to be safe. Syncs should be added wherever needed, but not more than needed. If you like microbenchmarks, you could compare (let's say with 1/3 writes, 2/3 reads): HashMap without sync, HashMap with syncs on writes, Hashtable, ConcurrentHashMap. I think there could be some more tuning being done for the attributes map (like setting a good initial size). Besides, this is a bit OT, and doesn't answer my question. I have just looked at two other popular servers source code, and some don't do any syncing for this, like Tomcat 5.0.x does. Overall, it means it's not portable, and the webapp really should plan on syncing on the session externally wherever needed. What I am willing to provide (this is the intent of the code in 5.5.x right now), by default, is making sure the HashMap cannot get corrupted, and that the infinite loop described in this report cannot occur. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36541] - session getAttribute/setAttribute and removeAttribute are NOT Thread safe.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36541. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36541 --- Additional Comments From [EMAIL PROTECTED] 2005-09-08 14:18 --- Overall, it means it's not portable, and the webapp really should plan on syncing on the session externally wherever needed. If you use different techniques this might become pain. It might be hard to tell everyone to synchronize against session, and in the end you have the same as synchronize in the base class. Well not really the same as tomcat can synchronize against the map, we have to synchronize on a wider context - the session. What I am willing to provide (this is the intent of the code in 5.5.x right now), by default, is making sure the HashMap cannot get corrupted, and that the infinite loop described in this report cannot occur. I wonder how this can be done? You might have to introduce your own map implementation, no? Is it possible to create a thread-safe hash-map without synchronization? Ok, if two threads put in an element with the same key it might not be deterministic which of both are really set then, but this is not the problem we have to solve. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36541] - session getAttribute/setAttribute and removeAttribute are NOT Thread safe.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36541. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36541 --- Additional Comments From [EMAIL PROTECTED] 2005-09-08 14:59 --- (In reply to comment #33) Overall, it means it's not portable, and the webapp really should plan on syncing on the session externally wherever needed. If you use different techniques this might become pain. It might be hard to tell everyone to synchronize against session, and in the end you have the same as synchronize in the base class. Well not really the same as tomcat can synchronize against the map, we have to synchronize on a wider context - the session. You indeed have to sync on a wider context in many cases. What I am willing to provide (this is the intent of the code in 5.5.x right now), by default, is making sure the HashMap cannot get corrupted, and that the infinite loop described in this report cannot occur. I wonder how this can be done? You might have to introduce your own map implementation, no? No, because at this point I believe making sure that the HashMap does not get corrupted (using syncs on put and remove) is enough to guarantee that the get method doesn't enter an infinite loop (by returning null, or the result when there's a problem - it will be unpredictable, but seems to me equivalent to the higher level concurrency issues if you mix and match reads/writes in the webapp for critical data without being careful). Other than this, it doesn't look that the collection being used with its default parameters is that optimal. Is it possible to create a thread-safe hash-map without synchronization? Ok, if two threads put in an element with the same key it might not be deterministic which of both are really set then, but this is not the problem we have to solve. Maybe using a fully array based structure rather than a linked list would make it more robust (ie, reads could be bad, writes could be lost, but the structure would remain consistent). There is stuff like ConcurrentHashMap, but it of course does synchronization of its own. I did agree previously (hence the current code in the 5.5 branch) that robustness is good, and that the HashMap structure should be protected, as there's no way to restore it, so there are syncs for put and remove. Since there's a real demand and you guys are quite persistent, I now agree on adding an extra configuration parameter on the context allowing to define the sweet spot for the collection size, as well as its synchronization policy (the default being the current 5.5 behavior, unless/until it is shown to still be able to cause the inifinite loop originally described in the report). -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36541] - session getAttribute/setAttribute and removeAttribute are NOT Thread safe.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36541. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36541 --- Additional Comments From [EMAIL PROTECTED] 2005-09-08 15:03 --- How do we approach the specifications committee for official clarification of this point. Who is going to take charge to actively do that? Here is hoping to provoke all vendors to take a look at the issue and report back to the committee foir a verdict in the coming months. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36541] - session getAttribute/setAttribute and removeAttribute are NOT Thread safe.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36541. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36541 --- Additional Comments From [EMAIL PROTECTED] 2005-09-08 15:14 --- (In reply to comment #34) No, because at this point I believe making sure that the HashMap does not get corrupted (using syncs on put and remove) is enough to guarantee that the get method doesn't enter an infinite loop (by returning null, or the result when there's a problem - it will be unpredictable, but seems to me equivalent to the higher level concurrency issues if you mix and match reads/writes in the webapp for critical data without being careful). I understand the point that others are making for all access needing the same sychronization. I don't understand your logic that read/get don't need syncronization. The issue with the infinite loop read stems from the fact that two different threads access the map at the same time. One for read and one for write, while the writer is modifying the map it corrupted the pointers the reader is using to traverse the data structures and thus enters an infinite loop (due to the HashMap design, other collection classes can detect some situations and throw an exception for ConcurrentAccessException). This is because there is no synchrnozation between get/put operations. Only between puts. As I pointed out in the TC user mailing list, it would be possible to use a ReadWriteLock to allow threading of multiple readers to take place. But while there is one writer working on the Map you need to be sure no reader is using the map too. Introducing the ReadWriteLock might introduce an unwanted JDK5 dependancy, I think its a new JDK5 concurrency class ? It might also be slower than a regular synchronized lock. But without benchmarks we wont know. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36541] - session getAttribute/setAttribute and removeAttribute are NOT Thread safe.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36541. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36541 --- Additional Comments From [EMAIL PROTECTED] 2005-09-08 15:20 --- (In reply to comment #36) One for read and one for write, while the writer is modifying the map it corrupted the pointers the reader is using to traverse the data structures and thus enters an infinite loop Sorry to reply to my own post, but my use of the word corrupted is a bad choice. In the normal operation of a write modification to the map the internal data structures are altered into a temporary inconsitant state. This inconsitancy is part of the normal working of the write operation. When the write operation returns to the application the map integrity is always consistant. The basic contract is true of all object design, unless otherwise stated to be thread safe. Which we all agree HashMap is not. If the read operations happens to bump into this moment of temporary inconsistacy the infinite loop can occur. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36558] New: - IntrospectionUtils caches application classes
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36558. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36558 Summary: IntrospectionUtils caches application classes Product: Tomcat 5 Version: 5.5.9 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Catalina AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] The class org.apache.tomcat.util.IntrospectionUtils caches the methods of classes used as parameters to the findMethods() method. This cache has hard references, so when used against an application class (often an exception), the classloader of that application will never be unloaded. Notice that changing the cache to a WeakHashMap would not help, as the class reference is also inside the Method object stored in the value field. I think the same class (IntrospectionUtils) exists in the commons-modeler library, with the same problem. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36113] - Session persistence for objects with primitive types
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=36113.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=36113
--- Additional Comments From [EMAIL PROTECTED] 2005-09-08 15:30 ---
Hi, I tried your code and it works correctly for session persistence in my case.
Although my approch would be faster (because only one exception is caught until
the result is returned in case of a primitive type), I agree to better not cut
and paste code (this is object orientated programming, isn't it ?).
Keep in mind to also change the ReplicationStream class in clustering.
Something like:
public Class resolveClass(ObjectStreamClass classDesc)
throws ClassNotFoundException, IOException {
String name = classDesc.getName();
boolean tryRepFirst = name.startsWith(org.apache.catalina.cluster);
try {
try
{
if ( tryRepFirst ) return findReplicationClass(name);
else return findWebappClass(name);
}
catch ( Exception x )
{
if ( tryRepFirst ) return findWebappClass(name);
else return findReplicationClass(name);
}
}
catch (ClassNotFoundException e)
{
return super.resolveClass (classDesc);
}
}
Thanks, Marcus
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36541] - session getAttribute/setAttribute and removeAttribute are NOT Thread safe.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36541. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36541 --- Additional Comments From [EMAIL PROTECTED] 2005-09-08 15:41 --- (In reply to comment #37) If the read operations happens to bump into this moment of temporary inconsistacy the infinite loop can occur. All the entry objects will be mutated. While it may be inconsistent and might loop for an instant (although I am not convinced this could really be the case; I think the trouble without any sync could only occur if there was more than one concurrent unsynced write, and in particular, two remove), the pointer value will be corrected and the loop should exit. That's my interpretation looking at the code. I think I'll write a small program to test this. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36558] - IntrospectionUtils caches application classes
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36558. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36558 --- Additional Comments From [EMAIL PROTECTED] 2005-09-08 15:42 --- There is more information about the general problem of not being able to GC class loaders at this wiki page: http://opensource2.atlassian.com/confluence/spring/pages/viewpage.action? pageId=2669 -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36541] - session getAttribute/setAttribute and removeAttribute are NOT Thread safe.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36541. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36541 --- Additional Comments From [EMAIL PROTECTED] 2005-09-08 15:54 --- (In reply to comment #38) All the entry objects will be mutated. While it may be inconsistent and might loop for an instant (although I am not convinced this could really be the case; I think the trouble without any sync could only occur if there was more than one concurrent unsynced write, and in particular, two remove), the pointer value will be corrected and the loop should exit. That's my interpretation looking at the code. I think I'll write a small program to test this. Let me ask you another question then. Where is the written specification for the HashMap that states your usage is safe ? It sounds like you as working on the presumption that all implementation's won't cause an infinite loop (or set fire to the computer) but you dont have any API contract to back that presumption up. I read the specification to state that some put/remove operations (that modify the map structurally are explicitly not threadsafe) You can't call threadsafe and non-threadsafe calls to an API at the same time. The threadsafe calls are only threadsafe with respect to other threadsafe calls on the same API. My understanding of this: You can call threadsafe API calls at the same time. Anytime you want to call a non-threadsafe one you have to serialize it with respect to the API Interface not with respect to itself or other similar operations (unless otherwise stated). -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36541] - session getAttribute/setAttribute and removeAttribute are NOT Thread safe.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36541. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36541 --- Additional Comments From [EMAIL PROTECTED] 2005-09-08 16:27 --- (In reply to comment #39) Let me ask you another question then. Where is the written specification for the HashMap that states your usage is safe ? It sounds like you as working on the presumption that all implementation's won't cause an infinite loop (or set fire to the computer) but you dont have any API contract to back that presumption up. I read the specification to state that some put/remove operations (that modify the map structurally are explicitly not threadsafe) You can't call threadsafe and non-threadsafe calls to an API at the same time. The threadsafe calls are only threadsafe with respect to other threadsafe calls on the same API. My understanding of this: You can call threadsafe API calls at the same time. Anytime you want to call a non-threadsafe one you have to serialize it with respect to the API Interface not with respect to itself or other similar operations (unless otherwise stated). I guess if it goes back again to lawyerspeak level rather than logic, then there's nothing to talk about. It is all related to reasonable reliability and robustness, and I don't believe the algorithm of a hashmap can become that weird (the Sun structure is already not particularly safe). I mean, there could even be bugs in the collection implementation too. I'd like to remind you once more that this synchronization in the container is not mandatory from what I can see, and at least one other popular container apparently behaves like Tomcat 5.0. It's the end of this discussion thread as far as I am concerned :) I'll also add a way to configure size and sync of the collection (assuming I confirm behavior to be acceptable using a test program). -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36558] - IntrospectionUtils caches application classes
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36558. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36558 --- Additional Comments From [EMAIL PROTECTED] 2005-09-08 16:30 --- The commons-modeler IntrospectionUtils should not be a problem for regular Tomcat operation. However, I see org.apache.tomcat.util.IntrospectionUtils is indeed used on exceptions that come out of the web application, so there is a problem for custom exception types. I will add a clear method to org.apache.tomcat.util.IntrospectionUtils as conserving the cache seems necessary. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36541] - session getAttribute/setAttribute and removeAttribute are NOT Thread safe.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36541. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36541 --- Additional Comments From [EMAIL PROTECTED] 2005-09-08 16:43 --- (In reply to comment #38) (In reply to comment #37) If the read operations happens to bump into this moment of temporary inconsistacy the infinite loop can occur. All the entry objects will be mutated. While it may be inconsistent and might loop for an instant (although I am not convinced this could really be the case; I think the trouble without any sync could only occur if there was more than one concurrent unsynced write, and in particular, two remove), the pointer value will be corrected and the loop should exit. That's my interpretation looking at the code. I think I'll write a small program to test this. You can certinaly get null returned when a valid value was added to the Map previosly as well because of the inconsistency. The hash index used to locate the first Entry is based on the hash and the length of the table (I guess we should say the chosen bucket). If the value has been added to the map. Then a call for a get occurs and a call for a write and the write makes a resize and the resize changes the location of the bucket then e could match another Entry besides the one for the correct hash then you start getting into some looping. In a test I had a get interation of 4 times occur when this happened, but considering all of the possible shifting that can occur I'm not convinced that an infinite loop could not occur. Given the bucket index algorithm and all of the possible values for a hash and a table size I don't think one can safely say it's not possible without synchronizing. If there is a way to determine that the behavior of one search for a bucket with any hash is always going to produce the same result for any size table then I think you can safely not synchronize the code.(In reply to comment #38) (In reply to comment #37) If the read operations happens to bump into this moment of temporary inconsistacy the infinite loop can occur. All the entry objects will be mutated. While it may be inconsistent and might loop for an instant (although I am not convinced this could really be the case; I think the trouble without any sync could only occur if there was more than one concurrent unsynced write, and in particular, two remove), the pointer value will be corrected and the loop should exit. That's my interpretation looking at the code. I think I'll write a small program to test this. You can certinaly get null returned when a valid value was added to the Map previosly as well because of the inconsistency. The hash index used to locate the first Entry is based on the hash and the length of the table (I guess we should say the chosen bucket). If the value has been added to the map. Then a call for a get occurs and a call for a write and the write makes a resize and the resize changes the location of the bucket then e could match another Entry besides the one for the correct hash then you start getting into some looping. In a test I had a get interation of 4 times occur when this happened, but considering all of the possible shifting that can occur I'm not convinced that an infinite loop could not occur. Given the bucket index algorithm and all of the possible values for a hash and a table size I don't think one can safely say it's not possible without synchronizing. If there is a way to determine that the behavior of one search for a bucket with any hash is always going to produce the same result for any size table then I think you can safely not synchronize the code. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36541] - session getAttribute/setAttribute and removeAttribute are NOT Thread safe.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36541. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36541 --- Additional Comments From [EMAIL PROTECTED] 2005-09-08 16:56 --- (In reply to comment #40) I read the specification to state that some put/remove operations (that modify the map structurally are explicitly not threadsafe) You can't call threadsafe and non-threadsafe calls to an API at the same time. The threadsafe calls are only threadsafe with respect to other threadsafe calls on the same API. There is nothing weird about anything. Its basic computer programming design. If you write a program what uses another API and you make presumtions about how you can use it then you will come unstuck, not matter what any servlet specification says. If however you base it on whats is written into the contract of what the API presents to your application then you can legitimatly point the finger at that API when you find a problem. Maybe you should write your own Map interface to get the bahaviour you want, I think a generic ReadWriteLock protected Map interface would be a good thing for the wider Java community to have access to. Your approach for writing a test case to prove the problem is valid, because its a concurrency rare case, maybe if you sprinckled Thread.sleep() throughout the HashMap code to slow it down the you might be able to make the problem 100% reproducable. But I don't believe Sun's implementation needs to be fixed, as this problem does not seem to contradict the written contract the HashMap API presents. I'd like to remind you once more that this synchronization in the container is not mandatory from what I can see And I'm not disputing you. I'm disputing the more fundimental usage problem. There is no way for a wep-app to override the Session object in a portable way across containers. I'll also add a way to configure size and sync of the collection (assuming I confirm behavior to be acceptable using a test program). This would be welcomed by me. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36541] - session getAttribute/setAttribute and removeAttribute are NOT Thread safe.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36541. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36541 --- Additional Comments From [EMAIL PROTECTED] 2005-09-08 16:58 --- (In reply to comment #38) I think the trouble without any sync could only occur if there was more than one concurrent unsynced write, and in particular, two remove), the pointer value will be corrected and the loop should exit. That's my interpretation looking at If I understand this statement correctly - You are saying that syncing the put and remove should be enough to stop the infinite loop, and that this is why it was FIXED in 5.5. If an example could be provided that an unsynced get can lead to an infinite loop, would this change anything concerning the status of this problem? A second question following on from this: When would anyone want to use a threadUnsafe session set/getAttribute? As we have seen, NOT syncing this causes hangs - so therefore developer needs to do this (if he uses these methods). Wouldn't it make more sense to just sync it further down in tomcat, as suggested here, rather than needing to sync the whole method every single time you use this in your code? -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36541] - session getAttribute/setAttribute and removeAttribute are NOT Thread safe.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36541. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36541 --- Additional Comments From [EMAIL PROTECTED] 2005-09-08 17:00 --- I guess I should add that it seems logical if one web page calls Session.setAttribute then it shouldn't be possible later to make a call to getAttribute and it not be available. i.e. a minute earlier I made a call to set then a minute later during my get a resize occurs and I get a null even though I should not get a null. This could occur because of the bucket distribution on certain hash and table size combinations vary. I had one hash and table combination yield a 9 index. Later when the resize occured this index was moved to 3, and the resize before that it was moved to 11. So, start at 9, resize, then to 11, resize, then to 3. So you can imagine what would happen if during the time I get the hash from indexFor and then access the array what I might getnull. This all in HashMap.get -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-connectors/util/java/org/apache/tomcat/util IntrospectionUtils.java
remm2005/09/08 08:00:57
Modified:catalina/src/share/org/apache/catalina/loader
WebappClassLoader.java
webapps/docs changelog.xml
util/java/org/apache/tomcat/util IntrospectionUtils.java
Log:
- 36558: Clear introspection utils cache, which could leak a reference to the
webapp classloader.
Revision ChangesPath
1.50 +4 -1
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/loader/WebappClassLoader.java
Index: WebappClassLoader.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/loader/WebappClassLoader.java,v
retrieving revision 1.49
retrieving revision 1.50
diff -u -r1.49 -r1.50
--- WebappClassLoader.java4 May 2005 07:30:24 - 1.49
+++ WebappClassLoader.java8 Sep 2005 15:00:54 - 1.50
@@ -56,6 +56,7 @@
import org.apache.naming.JndiPermission;
import org.apache.naming.resources.Resource;
import org.apache.naming.resources.ResourceAttributes;
+import org.apache.tomcat.util.IntrospectionUtils;
import org.apache.tomcat.util.compat.JdkCompat;
/**
@@ -1514,6 +1515,8 @@
org.apache.commons.logging.LogFactory.release(this);
// Clear the classloader reference in the VM's bean introspector
java.beans.Introspector.flushCaches();
+// Clear the IntrospectionUtils cache
+IntrospectionUtils.clear();
}
1.370 +4 -0 jakarta-tomcat-catalina/webapps/docs/changelog.xml
Index: changelog.xml
===
RCS file: /home/cvs/jakarta-tomcat-catalina/webapps/docs/changelog.xml,v
retrieving revision 1.369
retrieving revision 1.370
diff -u -r1.369 -r1.370
--- changelog.xml 8 Sep 2005 10:45:14 - 1.369
+++ changelog.xml 8 Sep 2005 15:00:54 - 1.370
@@ -52,6 +52,10 @@
fix
bug36534/bug: fix equals for URLs returned by
ServletContext.getResource() (luehe)
/fix
+ fix
+bug36558/bug: Clear IntrospectionUtils cache when stopping a
webapp, as it
+could leak to keeping a reference to the classloader (remm)
+ /fix
/changelog
/subsection
1.16 +4 -0
jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/IntrospectionUtils.java
Index: IntrospectionUtils.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/util/java/org/apache/tomcat/util/IntrospectionUtils.java,v
retrieving revision 1.15
retrieving revision 1.16
diff -u -r1.15 -r1.16
--- IntrospectionUtils.java 26 Jun 2005 21:19:28 - 1.15
+++ IntrospectionUtils.java 8 Sep 2005 15:00:55 - 1.16
@@ -757,6 +757,10 @@
}
// other utils
+public static void clear() {
+objectMethods.clear();
+}
+
public static String[] findVoidSetters(Class c) {
Method m[] = findMethods(c);
if (m == null)
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36541] - session getAttribute/setAttribute and removeAttribute are NOT Thread safe.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36541. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36541 --- Additional Comments From [EMAIL PROTECTED] 2005-09-08 17:03 --- (In reply to comment #44) I guess I should add that it seems logical if one web page calls Session.setAttribute then it shouldn't be possible later to make a call to getAttribute and it not be available. i.e. a minute earlier I made a call to set then a minute later during my get a resize occurs and I get a null even though I should not get a null. This could occur because of the bucket distribution on certain hash and table size combinations vary. I had one hash and table combination yield a 9 index. Later when the resize occured this index was moved to 3, and the resize before that it was moved to 11. So, start at 9, resize, then to 11, resize, then to 3. So you can imagine what would happen if during the time I get the hash from indexFor and then access the array what I might getnull. This all in HashMap.get This even without speaking of the infinite loop issue. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Top Level Project? Time for Top Level Lists?
Folks, as Tomcat is now (IIUC) a TLP, is it time to break apart the single dumping ground, fondly known as tomcat-dev, into multiple lists for folks with more targeted issues? E.g. [EMAIL PROTECTED] - our friend, this list [EMAIL PROTECTED] - svn/cvs commits [EMAIL PROTECTED] - bugzilla/jira reports I bring this up because, for example, I don't monitor the bugzilla noise as an email stream much, but want to continue to actively monitor cvs commits, and development chatter. I can see some [EMAIL PROTECTED] types who would be interested in following [EMAIL PROTECTED], but who have little to no interest in watching commits@ fly by. So I, for one, would be most appreciative of splitting the traffic; I already do split it in my email client, but I think this would be a help to many participants. [Especially if, for example, you want the dev@ traffic to go to a higher priority email account, and have the commits/issues type traffic hit your lower priority account.] Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Top Level Project? Time for Top Level Lists?
William A. Rowe, Jr. wrote: Folks, as Tomcat is now (IIUC) a TLP, is it time to break apart the single dumping ground, fondly known as tomcat-dev, into multiple lists for folks with more targeted issues? E.g. [EMAIL PROTECTED] - our friend, this list [EMAIL PROTECTED] - svn/cvs commits [EMAIL PROTECTED] - bugzilla/jira reports Right now, we have dev, user, and that's it. We need pmc too. I don't care personally about commits and issues (personally, I don't care, I have separate mail filters for the commits). I don't monitor the bugzilla noise This takes a whole new meaning for me now. as an email stream much, but want to continue to actively monitor cvs commits, and development chatter. I can see some [EMAIL PROTECTED] types who would be interested in following [EMAIL PROTECTED], but who have little to no interest in watching commits@ fly by. So I, for one, would be most appreciative of splitting the traffic; I already do split it in my email client, but I think this would be a help to many participants. [Especially if, for example, you want the dev@ traffic to go to a higher priority email account, and have the commits/issues type traffic hit your lower priority account.] Of course, but also fewer people will care about bug reports. Rémy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
cvs commit: jakarta-tomcat-catalina/webapps/docs changelog.xml
remm2005/09/08 08:41:11
Modified:modules/cluster/src/share/org/apache/catalina/cluster/session
ReplicationStream.java
catalina/src/share/org/apache/catalina/util
CustomObjectInputStream.java
webapps/docs changelog.xml
Log:
- 36113: Session persistence for objects with primitive types.
- The best fix would be to be able to reuse the JDK code (or similar) here.
Revision ChangesPath
1.5 +14 -10
jakarta-tomcat-catalina/modules/cluster/src/share/org/apache/catalina/cluster/session/ReplicationStream.java
Index: ReplicationStream.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/modules/cluster/src/share/org/apache/catalina/cluster/session/ReplicationStream.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- ReplicationStream.java27 Jul 2005 15:11:40 - 1.4
+++ ReplicationStream.java8 Sep 2005 15:41:11 - 1.5
@@ -69,15 +69,19 @@
throws ClassNotFoundException, IOException {
String name = classDesc.getName();
boolean tryRepFirst = name.startsWith(org.apache.catalina.cluster);
-try
-{
-if ( tryRepFirst ) return findReplicationClass(name);
-else return findWebappClass(name);
-}
-catch ( Exception x )
-{
-if ( tryRepFirst ) return findWebappClass(name);
-else return findReplicationClass(name);
+try {
+try
+{
+if ( tryRepFirst ) return findReplicationClass(name);
+else return findWebappClass(name);
+}
+catch ( Exception x )
+{
+if ( tryRepFirst ) return findWebappClass(name);
+else return findReplicationClass(name);
+}
+} catch (ClassNotFoundException e) {
+return super.resolveClass(classDesc);
}
}
1.5 +7 -2
jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/util/CustomObjectInputStream.java
Index: CustomObjectInputStream.java
===
RCS file:
/home/cvs/jakarta-tomcat-catalina/catalina/src/share/org/apache/catalina/util/CustomObjectInputStream.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- CustomObjectInputStream.java 10 Mar 2005 23:54:45 - 1.4
+++ CustomObjectInputStream.java 8 Sep 2005 15:41:11 - 1.5
@@ -70,7 +70,12 @@
*/
public Class resolveClass(ObjectStreamClass classDesc)
throws ClassNotFoundException, IOException {
-return Class.forName(classDesc.getName(), false, classLoader);
+try {
+return Class.forName(classDesc.getName(), false, classLoader);
+} catch (ClassNotFoundException e) {
+// Try also the superclass because of primitive types
+return super.resolveClass(classDesc);
+}
}
1.371 +4 -0 jakarta-tomcat-catalina/webapps/docs/changelog.xml
Index: changelog.xml
===
RCS file: /home/cvs/jakarta-tomcat-catalina/webapps/docs/changelog.xml,v
retrieving revision 1.370
retrieving revision 1.371
diff -u -r1.370 -r1.371
--- changelog.xml 8 Sep 2005 15:00:54 - 1.370
+++ changelog.xml 8 Sep 2005 15:41:11 - 1.371
@@ -56,6 +56,10 @@
bug36558/bug: Clear IntrospectionUtils cache when stopping a
webapp, as it
could leak to keeping a reference to the classloader (remm)
/fix
+ fix
+bug36113/bug: Session persistence for objects with primitive
types could fail in
+some rare cases (remm)
+ /fix
/changelog
/subsection
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36113] - Session persistence for objects with primitive types
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36113. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36113 [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2005-09-08 17:41 --- I have applied the proposed patch. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36558] - IntrospectionUtils caches application classes
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36558. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36558 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2005-09-08 17:42 --- I added a clear method which is called when stopping the classloader, so the issue is fixed in org.apache.tomcat.util.IntrospectionUtils. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36541] - session getAttribute/setAttribute and removeAttribute are NOT Thread safe.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=36541.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=36541
--- Additional Comments From [EMAIL PROTECTED] 2005-09-08 17:51 ---
(In reply to comment #43)
When would anyone want to use a threadUnsafe session set/getAttribute?
As we have seen, NOT syncing this causes hangs - so therefore developer
needs to do this (if he uses these methods). Wouldn't it make more sense to
just sync it further down in tomcat, as suggested here, rather than needing
to sync the whole method every single time you use this in your code?
One possible case is for a really simple dumb cache: where you expect the
result to be present in the session on every time except the first (eg where
the read:write ratio is 1:1). In such a case, if the get is
unsynchronized, it's safe to say:
Object cached = session.get(key);
if (cached == null) {
synchronized (session) {
cached = session.get(key);
if (cached == null) {
cached = blah;
session.put(key, cached);
}
}
}
I understand there is potential waste doing two gets (one in and one out of
synchronized block), but this only gets executed on the first hit, so
decreases in significance as the read:write ratio goes up.
Anyway - that's one case I've found where an un-threadsafe get helps
performance wise, especially on lower spec machines short on memory (only
through subjective observations though - don't have any numbers).
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36541] - session getAttribute/setAttribute and removeAttribute are NOT Thread safe.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36541. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36541 --- Additional Comments From [EMAIL PROTECTED] 2005-09-08 17:56 --- I guess the point of the above would be that desired synchronization behaviour is usage-dependent, so giving the developer the freedom/responsibility to decide it is not necessarily a bad thing. Personally my reading of the spec was that this was the reason it was left to the developer: because only the developer has a good idea what the desired sync behaviour is. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36541] - session getAttribute/setAttribute and removeAttribute are NOT Thread safe.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36541. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36541 --- Additional Comments From [EMAIL PROTECTED] 2005-09-08 18:03 --- (In reply to comment #47) I guess the point of the above would be that desired synchronization behaviour is usage-dependent, so giving the developer the freedom/responsibility to decide it is not necessarily a bad thing. Personally my reading of the spec was that this was the reason it was left to the developer: because only the developer has a good idea what the desired sync behaviour is. It would be fine if all the other places in Tomcat were fixed to allow you to do that. Point in case jsp:useBean with scope=session can't be synchronized..not that I know of without changing the TC5.0 and 5.5 code. Also the JSTL libraries, and many other jakarta libraries. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Top Level Project? Time for Top Level Lists?
Remy Maucherat wrote: Of course, but also fewer people will care about bug reports. Perhaps; perhaps not. In my case, I prefer to use the tool, and take advantage of the whole bugzilla/jira feature set. Bug emails are noise, because they scream me, me!, instead of reflecting on all the long outstanding, quiet bugs. Just two different perspectives, I guess. Bill - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36541] - session getAttribute/setAttribute and removeAttribute are NOT Thread safe.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36541. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36541 --- Additional Comments From [EMAIL PROTECTED] 2005-09-08 18:05 --- (In reply to comment #46) One possible case is for a really simple dumb cache: where you expect the result to be present in the session on every time except the first (eg where the read:write ratio is 1:1). In such a case, if the get is unsynchronized, it's safe to say: I understand, but how can you guarantee that the 'second' request does not overtake the first put request? Not very likely, agreed - but still possible. Users have a great way at pressing F5 very quickly! -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36541] - session getAttribute/setAttribute and removeAttribute are NOT Thread safe.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36541. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36541 --- Additional Comments From [EMAIL PROTECTED] 2005-09-08 18:10 --- (In reply to comment #49) I understand, but how can you guarantee that the 'second' request does not overtake the first put request? Not very likely, agreed - but still possible. Users have a great way at pressing F5 very quickly! That was the purpose of the second get check inside the sync block. The second request will, if the cache is null, block on the sync'd session, and only proceed into the sync block after the put. The first thing it does is check again, which returns non null and it continues happily. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36541] - session getAttribute/setAttribute and removeAttribute are NOT Thread safe.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36541. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36541 --- Additional Comments From [EMAIL PROTECTED] 2005-09-08 18:14 --- (In reply to comment #50) That was the purpose of the second get check inside the sync block. The second request will, if the cache is null, block on the sync'd session, and only proceed into the sync block after the put. The first thing it does is check again, which returns non null and it continues happily. The situation can occur IF the second request overtakes the first that Object cached = session.get(key) will simply not come back and return null, because it hangs in the hashmap inside the get and so your check for null will never be called -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36541] - session getAttribute/setAttribute and removeAttribute are NOT Thread safe.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36541. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36541 --- Additional Comments From [EMAIL PROTECTED] 2005-09-08 18:14 --- Bear in mind if you are using clustering, you have to put the modified session attribute after you have finished modifying the object and wish the new state to persist for the next request, as clutering replication only takes place at setAttribute() time. So the 1000:1 may only be realistic for those users. Also with the other issue of getting a null back when you expected to see an object. Session data does not stay around forever, it expires so all web-apps must deal with the no session situation. So I'd agree that so long as your servlet still holds the exact Session object instance you did a setAttribute() on you can reasonable expect a getAttribute() on it exist. But between requests you let go of the instance, and leave it upto the container session manager to hold onto. If as comment #44 implies you are talking minutes later, then I read into that you mean across requests. Well there is no garuntee your session still exists so your web-app must deal with that situation. But you should not need to deal with seeing an old overwritten value turn up again, that would be a problem. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36541] - session getAttribute/setAttribute and removeAttribute are NOT Thread safe.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36541. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36541 --- Additional Comments From [EMAIL PROTECTED] 2005-09-08 18:16 --- (In reply to comment #35) How do we approach the specifications committee for official clarification of this point. Who is going to take charge to actively do that? Here is hoping to provoke all vendors to take a look at the issue and report back to the committee foir a verdict in the coming months. The formal mechanism to do that is send email to the feedback address listed on the spec (for 2.4, that's servletapi-feedback AT eng.sun.com). I've done that, and corresponded privately with the spec lead for Servlet 2.5 (Greg Murray) as well, who will then discuss it with the expert group to see what (if any) language changes they might want to do in Servlet 2.5. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36541] - session getAttribute/setAttribute and removeAttribute are NOT Thread safe.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36541. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36541 --- Additional Comments From [EMAIL PROTECTED] 2005-09-08 18:17 --- (In reply to comment #48) (In reply to comment #47) I guess the point of the above would be that desired synchronization behaviour is usage-dependent, so giving the developer the freedom/responsibility to decide it is not necessarily a bad thing. Personally my reading of the spec was that this was the reason it was left to the developer: because only the developer has a good idea what the desired sync behaviour is. It would be fine if all the other places in Tomcat were fixed to allow you to do that. Point in case jsp:useBean with scope=session can't be synchronized..not that I know of without changing the TC5.0 and 5.5 code. Also the JSTL libraries, and many other jakarta libraries. Also if you access the PageContext in a jsp and use the scoped methods the ones accessing APPLICATION and REQUEST scope are already synchronized, yet the session is not. Also, now you have to synchronize not only session calls, but you also have to synchronize the calls to the PageContext in a JSP. So, instead of some type of a performance gain you end up with double the monitors for those objects and then the one for the session. I think these are the points people are making.there is so much to change now that a patch now and maybe a refactoring could be done and an announcement that the functionality is changing. But, before TC decides to do that maybe they should see how all of the other servers are handling this. Because if they are handing this with synchronization and others are writing code not worrying about synchronizingthey are not going to rewrite to use Tomcat later and what about code targeted for a container like Oracle or Sun ONE that someone is using in TC which is not synchronized...point being if the user base gets run off whats the point, and who will be left donating to the project. I really think this is too subtle of a thing to say it's by the specat least for the time being, and maybe it should always and forever remain synchronized depending on what is going on with the real world usage of the spec in other cases. There are other situations where you don't even have access to synchronize the call...again tags, and I'm sure some other API calls directly manipulating the session. I have found no where in other Tomcat code synchronizing the session access, so there are other issues or fix this one. I haven't even seen comments on all of the other issues in the TC code accessing the session or the other jakarta projects from anyone but those arguing this needs to be fixed. So, what's the story? Is this one thing changing or are all of the others changing or is nothing changing (being fixed)? -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36541] - session getAttribute/setAttribute and removeAttribute are NOT Thread safe.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36541. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36541 --- Additional Comments From [EMAIL PROTECTED] 2005-09-08 18:47 --- (In reply to comment #38) All the entry objects will be mutated. While it may be inconsistent and might loop for an instant (although I am not convinced this could really be the case; I think the trouble without any sync could only occur if there was more than one concurrent unsynced write, and in particular, two remove), the pointer value will be corrected and the loop should exit. That's my interpretation looking at the code. I think I'll write a small program to test this. Ok, I wrote a program which can reproduce the bug even with tomcat 5.5 conditions, with synchronized put/remove and unsynchronized get. I must correct myself, since it doesn't produce an infinite loop, but just a very LONG LASTING FINITE loop, and I am talking about hours or days of execution. I do following: Having X writer and X reader threads, which modify (set or remove by 50% chance) and read 10 mappings concurrently. The abovementioned bug occurs pretty soon (500.000 operations), the read thread hangs around for 5-10 seconds and gets fixed by the writer thread some time later. I've measured that a read operation lasts on average 0.01-0.02 milliseconds. So if one of the threads detects that last execution lasted longer then 5 seconds it is safe to say that this thread was hanging and got fixed by another writer. Speaking of that, we could probably reproduce it on the production servers by not restarting them, and leting them run some hours or days instead (maybe as long as the user is still online, I don't know) and hope they will get fixed. However this is not really a solution. The reason I can't reproduce the infinite loop, is that I can't stop the writers in time. Performing thousands of writes per second in multiple threads makes it hard to stop all writers at the same point, before they unintentionally fix the reader. Still, I assume, I have a good chance that an infinite loop happens on the production server if the user leaves the server, and no further write operations are performed on his session. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36562] New: - Possible typo in Connector
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36562. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36562 Summary: Possible typo in Connector Product: Tomcat 5 Version: 5.5.11 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Catalina AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] In src/share/org/apache/catalina/connector/Connector.setURIEncoding: setProperty(uRIEncoding, URIEncoding); Not sure what the intent is here, but would expect either URIEncoding uriEncoding. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36534] - Context relative URLs returned by ServletContext.getResource() for the same path are not equal
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36534. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36534 [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Top Level Project? Time for Top Level Lists?
William A. Rowe, Jr. wrote: Folks, as Tomcat is now (IIUC) a TLP, is it time to break apart the single dumping ground, fondly known as tomcat-dev, into multiple lists for folks with more targeted issues? E.g. [EMAIL PROTECTED] - our friend, this list [EMAIL PROTECTED] - svn/cvs commits [EMAIL PROTECTED] - bugzilla/jira reports I would prefer to continue with a single dev list. Reasons are: - Modern e-mail clients allow people to split it any way they like - Many archives are geared to searching one list at a time - Multiple lists raise the barrier (only slightly) to getting involved Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36389] - ignorable whitespace is not dropped from tag documents
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36389. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36389 --- Additional Comments From [EMAIL PROTECTED] 2005-09-08 21:57 --- Sorry, this is not a bug after all. I think I did not change my extension to tagx as required by the spec. JSP documents can keep the jsp extension used by pages but indicate that they are documents by other means, but JSP.8.6 says that tags with the tag extension are not in XML syntax. JSP.8.6 does say, however, that jsp:root cannot appear in a tag file with JSP syntax, and I believe I did this without any complaint in my attempt to indicate a .tag file was XML syntax. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36546] - AJP returns pages with text/plain content type
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36546. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36546 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2005-09-08 23:10 --- There is insufficient information in this bug report for us to investigate. missing information includes: - test case (smallest page that has the problem) - type of page (html, jsp, servlet) - httpd.conf settings for JK - worker.properties Chances are that this is a configuration issue. Please use the Tomcat user list to investigate this further where you are far more likely to get some useful resposnes. If the tomcat-user discussions conclude that this is a bug, please feel free to re-open this report and append the necessary information to reproduce it. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36541] - session getAttribute/setAttribute and removeAttribute are NOT Thread safe.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36541. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36541 --- Additional Comments From [EMAIL PROTECTED] 2005-09-08 23:31 --- Looks like the problem will hard to reproduce as it requires a situation where a write to the hashmap causes a table resize/reindex to occur while another thread is reading from the hashmap. I would have thought it would return a null when it couldn't find the value. But there is no guarantee on what happens. Developers could sync on the session everytime they want to read. But why should they, it is adding to the complexity of writing web apps. As Wade Chandler points out it may not even be possible with the JSTL tags. Some have suggested using ReadWriteLock or some other tricky method of reading, checking if null, and then doing a synced read. Which is all very good, but there is a simpler solution (for tomcat 5.5) - use ConcurrentHashMap - it says that Special-purpose data structures such as the Concurrent hash tables in this package have far less overhead, and typically much better performance than placing ReadWriteLocks around most sequential data structures. Also, the ConcurrentHashMap already does the second suggestion of doing a sync after a null is returned (if you look at the link at the end of this). Here you have someone who has done all this hard work of figuring out when you can read/write and deals with locking. It will give you consistant results, and takes out the opportunity for developers to make mistakes themselves with deciding whether to sync when reading from a session or not. Plus JSTL and everywhere else will benefit in not getting inconsistant results. Next stop, Application scope... some more reading about ConcurrentHashMap internals: http://www-128.ibm.com/developerworks/java/library/j-jtp08223/ -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35641] - Error decoding request in Tomcat server on submit of a jsp page
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35641. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35641 [EMAIL PROTECTED] changed: What|Removed |Added Status|CLOSED |REOPENED Resolution|INVALID | --- Additional Comments From [EMAIL PROTECTED] 2005-09-08 23:39 --- I am getting the exact same problem. When will this be fixed? Is there a new release slated soon? Sep 8, 2005 2:55:53 PM org.apache.jk.common.HandlerRequest invoke SEVERE: Error decoding request java.io.IOException at org.apache.jk.common.JkInputStream.receive(JkInputStream.java:252) at org.apache.jk.common.HandlerRequest.decodeRequest (HandlerRequest.java:500) at org.apache.jk.common.HandlerRequest.invoke(HandlerRequest.java:352) at org.apache.jk.common.ChannelSocket.invoke(ChannelSocket.java:743) at org.apache.jk.common.ChannelSocket.processConnection (ChannelSocket.java:675) at org.apache.jk.common.SocketConnection.runIt(ChannelSocket.java:866) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run (ThreadPool.java:683) at java.lang.Thread.run(Unknown Source) 12 34 0d a4 02 04 00 08 48 54 54 50 2f 31 2e 30 | .4.?HTTP/1.0 00 00 1f 2f 69 64 6d 2f 75 73 65 72 2f 47 45 54 | .../idm/user/GET 53 70 72 6f 63 65 73 73 4c 61 75 6e 63 68 2e 6a | SprocessLaunch.j 73 70 00 00 0b 33 2e 33 34 2e 32 32 31 2e 37 31 | sp...3.34.221.71 00 00 0b 33 2e 33 34 2e 32 32 31 2e 37 31 00 00 | ...3.34.221.71.. 13 69 64 6d 2e 74 72 65 61 73 75 72 79 2e 67 65 | .idm.treasury.ge 2e 63 6f 6d 00 01 bb 01 00 22 a0 01 00 a4 69 6d | .com..?..?..?im 61 67 65 2f 67 69 66 2c 20 69 6d 61 67 65 2f 78 | age/gif, image/x 2d 78 62 69 74 6d 61 70 2c 20 69 6d 61 67 65 2f | -xbitmap, image/ 6a 70 65 67 2c 20 69 6d 61 67 65 2f 70 6a 70 65 | jpeg, image/pjpe 67 2c 20 61 70 70 6c 69 63 61 74 69 6f 6e 2f 78 | g, application/x 2d 73 68 6f 63 6b 77 61 76 65 2d 66 6c 61 73 68 | -shockwave-flash 2c 20 61 70 70 6c 69 63 61 74 69 6f 6e 2f 76 6e | , application/vn 64 2e 6d 73 2d 65 78 63 65 6c 2c 20 61 70 70 6c | d.ms-excel, appl 69 63 61 74 69 6f 6e 2f 76 6e 64 2e 6d 73 2d 70 | ication/vnd.ms-p 6f 77 65 72 70 6f 69 6e 74 2c 20 61 70 70 6c 69 | owerpoint, appli 63 61 74 69 6f 6e 2f 6d 73 77 6f 72 64 2c 20 2a | cation/msword, * 2f 2a 00 a0 04 00 05 65 6e 2d 75 73 00 a0 06 00 | /*.?...en-us.?.. 0a 4b 65 65 70 2d 41 6c 69 76 65 00 a0 0b 00 13 | .Keep-Alive.?... 69 64 6d 2e 74 72 65 61 73 75 72 79 2e 67 65 2e | idm.treasury.ge. 63 6f 6d 00 a0 0d 00 3a 68 74 74 70 73 3a 2f 2f | com.?..:https:// 69 64 6d 2e 74 72 65 61 73 75 72 79 2e 67 65 2e | idm.treasury.ge. 63 6f 6d 2f 69 64 6d 2f 47 45 54 53 72 65 71 75 | com/idm/GETSrequ 65 73 74 2f 6e 65 77 52 65 71 75 65 73 74 2e 6a | est/newRequest.j 73 70 00 a0 0e 00 4a 4d 6f 7a 69 6c 6c 61 2f 34 | sp.?..JMozilla/4 2e 30 20 28 63 6f 6d 70 61 74 69 62 6c 65 3b 20 | .0 (compatible; 4d 53 49 45 20 36 2e 30 3b 20 57 69 6e 64 6f 77 | MSIE 6.0; Window 73 20 4e 54 20 35 2e 31 3b 20 53 56 31 3b 20 2e | s NT 5.1; SV1; . 4e 45 54 20 43 4c 52 20 31 2e 31 2e 34 33 32 32 | NET CLR 1.1.4322 29 00 a0 09 04 57 53 4d 53 45 53 53 49 4f 4e 3d | ).?..WSMSESSION= 52 59 65 4d 37 34 78 42 62 6d 48 62 4e 47 65 4c | RYeM74xBbmHbNGeL 4d 4a 66 45 58 41 72 47 7a 41 69 4d 76 35 34 56 | MJfEXArGzAiMv54V 50 38 55 54 48 74 78 33 53 75 50 64 4d 35 48 2f | P8UTHtx3SuPdM5H/ 56 61 36 65 38 76 6a 48 48 41 57 35 35 4c 47 49 | Va6e8vjHHAW55LGI 72 6e 5a 73 46 35 54 50 63 76 4d 6d 6e 56 54 72 | rnZsF5TPcvMmnVTr 6d 78 42 47 75 4e 45 38 71 74 71 31 70 46 38 70 | mxBGuNE8qtq1pF8p 61 37 56 2f 52 62 30 4e 56 75 7a 30 67 49 50 41 | a7V/Rb0NVuz0gIPA 41 66 41 62 65 2b 4f 6f 38 73 71 4e 79 70 34 2f | AfAbe+Oo8sqNyp4/ 79 6b 30 54 55 52 41 36 63 76 57 47 4a 71 69 70 | yk0TURA6cvWGJqip 72 53 6a 38 74 70 52 55 65 52 6c 75 6d 46 6d 56 | rSj8tpRUeRlumFmV 4f 58 6e 49 34 49 58 4e 47 66 66 6e 61 53 49 76 | OXnI4IXNGffnaSIv 55 78 77 6e 6f 57 46 41 43 4d 50 57 4e 46 75 4b | UxwnoWFACMPWNFuK 6a 41 6d 33 6b 75 55 37 49 73 4f 51 6b 6a 2f 64 | jAm3kuU7IsOQkj/d 61 37 41 33 53 52 77 4a 35 34 4f 73 55 45 4e 51 | a7A3SRwJ54OsUENQ 47 32 4f 6b 6d 38 71 54 74 54 4b 77 44 30 61 74 | G2Okm8qTtTKwD0at 34 71 64 6a 54 4d 54 55 6b 55 44 47 6d 53 6c 34 | 4qdjTMTUkUDGmSl4 36 69 42 4d 33 70 62 76 32 5a 52 39 35 49 45 2b | 6iBM3pbv2ZR95IE+ 72 41 4f 43 39 44 41 35 37 49 36 6b 55 74 65 4a | rAOC9DA57I6kUteJ 30 4f 46 44 46 64 53 75 39 72 42 73 59 75 47 62 | 0OFDFdSu9rBsYuGb 79 74 42 4a 34 33 5a 2f 62 56 33 61 4b 58 73 79 | ytBJ43Z/bV3aKXsy 76 69 4e 2b 33 30 68 50 54 76 31 46 49 54 56 46 | viN+30hPTv1FITVF 69 50 66 55 6e 57 44
DO NOT REPLY [Bug 36541] - session getAttribute/setAttribute and removeAttribute are NOT Thread safe.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36541. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36541 --- Additional Comments From [EMAIL PROTECTED] 2005-09-09 01:03 --- (In reply to comment #56) Looks like the problem will hard to reproduce as it requires a situation where a write to the hashmap causes a table resize/reindex to occur while another thread is reading from the hashmap. I would have thought it would return a null when it couldn't find the value. But there is no guarantee on what happens. It should return a null when you simply look at it the code. I can't reproduce the infinite loop myself, but Leon says he can reproduce the problem, and if it's so then it's a problem (Murphy's Law), and I definitely see that it is possible to add an attribute then later while a write is occuring to ... for instance ... be logged in to some application which is relying on session variables and the system think you are not then get kicked out because of concurrency issues in with the HashMap not being synchronized because the system thinks a session attribute/variable isn't set when it is. The original set could have occurred hours before then just when the read is occuring a write takes place which resizes the HashMap, and then an issue arises which makes web apps unpredictable in Tomcatyou can predict it by knowing the default size of the Map and not using more session variables than the Map threshold to size I suppose, but give me a break. I can't say for certain, myself, whether the infinite loop will occur just syncing the writes or not, but the way the get method works with the index being calculated for the hash bucket (array index) you can certainly say it's unpredictable and it can definitely cause goofy errors. So an INVALID resolution seems irresponsible for this issue. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36541] - session getAttribute/setAttribute and removeAttribute are NOT Thread safe.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36541. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36541 --- Additional Comments From [EMAIL PROTECTED] 2005-09-09 01:45 --- I assume that everyone has read the tomcat mailing list regarding this issue and seen and read the link pointing to http://blogs.opensymphony.com/plightbo/archives/000175.html So are we still arguing whether or not getAttribute can cause an infinite loop? or not? If we all agree that getAttribute can cause an infinite loop IF called in a multithreaded environment, we (I assume) all agree that the call to it MUST be synced SOMEWHERE. This also includes the example in comment 46, as it can not be gaurenteed that getAttribute (inside the session.get) in the first line does not happen in the middle of putAttribute in the middle of session.put. Now the last question is remaining is who's responsibility is it to sync it? If the end developers need to sync it - they will need to sync much more than just the 'hashmap' itself -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36541] - session getAttribute/setAttribute and removeAttribute are NOT Thread safe.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36541. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36541 --- Additional Comments From [EMAIL PROTECTED] 2005-09-09 02:10 --- (In reply to comment #58) I assume that everyone has read the tomcat mailing list regarding this issue and seen and read the link pointing to http://blogs.opensymphony.com/plightbo/archives/000175.html So are we still arguing whether or not getAttribute can cause an infinite loop? or not? If we all agree that getAttribute can cause an infinite loop IF called in a multithreaded environment, we (I assume) all agree that the call to it MUST be synced SOMEWHERE. This also includes the example in comment 46, as it can not be gaurenteed that getAttribute (inside the session.get) in the first line does not happen in the middle of putAttribute in the middle of session.put. Now the last question is remaining is who's responsibility is it to sync it? If the end developers need to sync it - they will need to sync much more than just the 'hashmap' itself Again though, when you look at all of the places accessing Session.getAttribute you can't synchronize all of them, so the last question that I see is what is going to be fixed? Either all of these other places in TC need to be fixed or this one does. But, I think a real world study should take place before all the other places are fixed and this one isn't. I mean, if all other containers are behaving like TC4.x and synchronizing these calls then it just makes sense for TC to follow suit. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36541] - session getAttribute/setAttribute and removeAttribute are NOT Thread safe.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36541. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36541 --- Additional Comments From [EMAIL PROTECTED] 2005-09-09 02:13 --- (In reply to comment #58) synced SOMEWHERE. This also includes the example in comment 46, as it can not be gaurenteed that getAttribute (inside the session.get) in the first line does not happen in the middle of putAttribute in the middle of session.put. Actually, after looking at this a bit more - I need to correct myself - this example works because the hashmap does not need to be resized on the first and only putAttribute call. Still - not very pretty though. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 35641] - Error decoding request in Tomcat server on submit of a jsp page
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=35641. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=35641 [EMAIL PROTECTED] changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||INVALID --- Additional Comments From [EMAIL PROTECTED] 2005-09-09 02:31 --- (In reply to comment #3) I am getting the exact same problem. When will this be fixed? Is there a new release slated soon? I certain that you won't see this exact error in 5.5.11+ ;-). There is nothing here to indicate a problem with Tomcat. It's possible that there is something in the mod_jk logs that indicates why mod_jk decided to drop the connection to Tomcat. However there is certainly not enough information here to even believe that there is anything here that requires fixing. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r279657 - in /tomcat/site/trunk: docs/findhelp.html docs/whichversion.html xdocs/findhelp.xml xdocs/whichversion.xml
On 9/8/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Author: markt Date: Thu Sep 8 15:13:43 2005 New Revision: 279657 snip/ Mark - Looking at this commit, it seems you might want to get some sweeping propset's in on svn:eol-style, and use these as auto-props for future svn additions, if you don't already [ http://www.apache.org/dev/svn-eol-style.txt ]. I also wonder why the CGI's from last night now bear LFs for eol-style (r279457,r279458). Can those be changed to native? Thanks for all the work. Just trying to save some grief later ;-) -Rahul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Diana L Greeninger/Graco is out of the office.
I will be out of the office starting 09/07/2005 and will not return until 09/12/2005. I will be out of the office starting 7/15/02 and will not be returning untill 7/22/02. I will respond to your message when I return.For immediate assistance , please contact Wendy Peterson @ x6231. Thanks , Diana - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Top Level Project? Time for Top Level Lists?
Remy Maucherat wrote: So I, for one, would be most appreciative of splitting the traffic; I already do split it in my email client, but I think this would be a help to many participants. [Especially if, for example, you want the dev@ traffic to go to a higher priority email account, and have the commits/issues type traffic hit your lower priority account.] Of course, but also fewer people will care about bug reports. I doubt that filling the inbox with the bug reports or commit messages will make anyone care more ( or make anyone read them when they don't want to ) :-) It seems most people use filters anyway, and those who don't ( like using gmane or a web-based interface ) just suffer the noise, but still ignore the bugs/commits they don't care about. I would really appreciate splitting them - I try to read tomcat-dev as much as possible, but web-based interfaces ( like gmane's RSS view or the html viewer ) are almost useless due to the noise, and filtering the news is not easy either. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 36541] - session getAttribute/setAttribute and removeAttribute are NOT Thread safe.
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=36541. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36541 --- Additional Comments From [EMAIL PROTECTED] 2005-09-09 07:35 --- Too much has said alread, but I also think it is not the only option to simply synchronize. Most of the time the different webapps/technologies do not utilize the same content of such a session map. e.g. JSF and your home app mostly wont use the same keys in this hashmap. So why introduce a bottleneck? (and I didnt mean a real performance one, its more philosophical) Why should one technique influence another one? And there is an impact, in the worst case this synchronized map acts like a sequencer. What I would like to say is, its somehow reasonable to not simply synchronize, but to find a hashmap which is able to handle this case. This hashmap should be able to insert keys in concurrent. I one insert the same key in parallel the result wont be deterministic, ok - fine. And for sure, such a map should not lock (and not even wait for some free me event) on get. Isnt there a cool java collection developer here? -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Small refactoring in Http11Processor
Hi,
I have a small patch, spliting the JMX-dependent code in
Http11Processor, i.e. the few lines of code dealing with the
registration of the thread pool and per thread data - and moving all
non-jmx code in a separate base class.
I know Tomcat5 is heavily dependent on JMX, but the connector can be
used in other containers, or it can be used standalone. This small
change won't affect any functionality on tomcat - all methods are used
only for intialization anyway, not in the critical path.
Please review and let me know if it's ok to commit the change.
Also, I would like to add another directory under j-t-c, with a build
file and few classes for a 'mini' experiment - i.e. using the connector
standalone, as a minimal http server, and also a target to build a
minimal servlet container as a single self-contained jar. We don't have
a sandbox, and j-t-c seems closest to that :-)
Costin
? src/java/org/apache/coyote/http11/Http11BaseProtocol.java
Index: src/java/org/apache/coyote/http11/Http11Protocol.java
===
RCS file:
/home/cvs/jakarta-tomcat-connectors/http11/src/java/org/apache/coyote/http11/Http11Protocol.java,v
retrieving revision 1.64
diff -b -u -w -r1.64 Http11Protocol.java
--- src/java/org/apache/coyote/http11/Http11Protocol.java 22 May 2005
17:12:11 - 1.64
+++ src/java/org/apache/coyote/http11/Http11Protocol.java 9 Sep 2005
05:31:50 -
@@ -56,98 +56,12 @@
* @author Remy Maucherat
* @author Costin Manolache
*/
-public class Http11Protocol implements ProtocolHandler, MBeanRegistration
+public class Http11Protocol extends Http11BaseProtocol implements
MBeanRegistration
{
public Http11Protocol() {
-cHandler = new Http11ConnectionHandler( this );
-setSoLinger(Constants.DEFAULT_CONNECTION_LINGER);
-setSoTimeout(Constants.DEFAULT_CONNECTION_TIMEOUT);
-setServerSoTimeout(Constants.DEFAULT_SERVER_SOCKET_TIMEOUT);
-setTcpNoDelay(Constants.DEFAULT_TCP_NO_DELAY);
+super();
}
-/**
- * The string manager for this package.
- */
-protected static StringManager sm =
-StringManager.getManager(Constants.Package);
-
-/** Pass config info
- */
-public void setAttribute( String name, Object value ) {
-if( log.isTraceEnabled())
-log.trace(sm.getString(http11protocol.setattribute, name,
value));
-
-attributes.put(name, value);
-}
-
-public Object getAttribute( String key ) {
-if( log.isTraceEnabled())
-log.trace(sm.getString(http11protocol.getattribute, key));
-return attributes.get(key);
-}
-
-public Iterator getAttributeNames() {
-return attributes.keySet().iterator();
-}
-
-/**
- * Set a property.
- */
-public void setProperty(String name, String value) {
-setAttribute(name, value);
-}
-
-/**
- * Get a property
- */
-public String getProperty(String name) {
-return (String)getAttribute(name);
-}
-
-/** The adapter, used to call the connector
- */
-public void setAdapter(Adapter adapter) {
-this.adapter=adapter;
-}
-
-public Adapter getAdapter() {
-return adapter;
-}
-
-
-/** Start the protocol
- */
-public void init() throws Exception {
-ep.setConnectionHandler( cHandler );
-try {
-checkSocketFactory();
-} catch( Exception ex ) {
-log.error(sm.getString(http11protocol.socketfactory.initerror),
- ex);
-throw ex;
-}
-
-if( socketFactory!=null ) {
-Enumeration attE=attributes.keys();
-while( attE.hasMoreElements() ) {
-String key=(String)attE.nextElement();
-Object v=attributes.get( key );
-socketFactory.setAttribute( key, v );
-}
-}
-
-// XXX get domain from registration
-try {
-ep.initEndpoint();
-} catch (Exception ex) {
-log.error(sm.getString(http11protocol.endpoint.initerror), ex);
-throw ex;
-}
-if(log.isInfoEnabled())
-log.info(sm.getString(http11protocol.init, getName()));
-
-}
ObjectName tpOname;
ObjectName rgOname;
@@ -178,460 +92,18 @@
( cHandler.global, rgOname, null );
}
-try {
-ep.startEndpoint();
-} catch (Exception ex) {
-log.error(sm.getString(http11protocol.endpoint.starterror), ex);
-throw ex;
-}
-if(log.isInfoEnabled())
-log.info(sm.getString(http11protocol.start, getName()));
-}
-
-public void pause() throws Exception {
-try {
-ep.pauseEndpoint();
-} catch (Exception ex) {
-log.error(sm.getString(http11protocol.endpoint.pauseerror), ex);
-throw ex;
-
