DO NOT REPLY [Bug 50950] NotSerializableException: org.apache.catalina.realm.GenericPrincipal
https://issues.apache.org/bugzilla/show_bug.cgi?id=50950 --- Comment #5 from Ronald Klop 2011-03-28 03:09:58 EDT --- Created an attachment (id=26803) --> (https://issues.apache.org/bugzilla/attachment.cgi?id=26803) full stacktrace Mmm, my (new) terminal doesn't copy what is outside the viewport. Now you have a complete stack. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 50983] New: IE 7 & 8 issues with docx and xlsx file extention
https://issues.apache.org/bugzilla/show_bug.cgi?id=50983 Summary: IE 7 & 8 issues with docx and xlsx file extention Product: Tomcat 6 Version: unspecified Platform: PC OS/Version: Windows XP Status: NEW Severity: major Priority: P2 Component: Manager application AssignedTo: dev@tomcat.apache.org ReportedBy: prakashjo...@gmail.com After providing mime mapping in the web.xml still IE 7 & 8 at client site cant download docx files with docx extension. IE open it as .zip file. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 50984] New: Manager application fails to report stranded artifacts when undeploying
https://issues.apache.org/bugzilla/show_bug.cgi?id=50984 Summary: Manager application fails to report stranded artifacts when undeploying Product: Tomcat 7 Version: 7.0.10 Platform: PC OS/Version: Linux Status: NEW Severity: major Priority: P2 Component: Manager AssignedTo: dev@tomcat.apache.org ReportedBy: fgalie...@gmail.com [NOTE: this is tomcat 7.0.11, not 7.0.10, but the version is not given as a choice, I therefore file it as 7.0.10, which I suspect has the same bug] Scenario: * tomcat starts, as user u1, with only the manager application in place; * it is configured as to not deploy automatically; * user u1 copies a webapp tree into $CATALINA_HOME/webapps, which it can since it has write/execute access to this directory; * the manager webapp is called to deploy that new web application; * [in between, credentials on the deployed webapp directory are changed so that user u1 cannot remove the webapp at all] * the manager webapp is called to undeploy that application, BUG: it answers OK, but it is not. The manager webapp documentation explicitly states that undeploying an application means that the webapp tree is removed - but of course, in this case it isn't. Use case below, where $CATALINA_HOME/webapps is a symlink to /var/lib/o3/tomcat/installs: # Only manager webapp running initially [o3@tomcat-r8 cockpit]$ wget -O - -q --http-user=tomcat --http-password=tomcat http://localhost:8080/manager/text/list|sed 1d /manager:running:6:/usr/share/tomcat7/webapps/manager # webapp tree is created by other means. Now deploying the application: [o3@tomcat-r8 cockpit]$ wget -O - -q --http-user=tomcat --http-password=tomcat http://localhost:8080/manager/text/deploy'?path=/cockpit&war=file:/var/lib/o3/tomcat/installs/cockpit' OK - Deployed application at context path /cockpit [...] # In another terminal: [root@tomcat-r8 installs]# pwd /var/lib/o3/tomcat/installs # All files are created with umask 022. Just change the owner: [root@tomcat-r8 installs]# chown -R root.root cockpit/ [...] # Back to the first terminal: [o3@tomcat-r8 cockpit]$ wget -O - -q --http-user=tomcat --http-password=tomcat http://localhost:8080/manager/text/undeploy?path=/cockpit OK - Undeployed application at context path /cockpit # Here is the bug: even though the command returns OK, the tree still exists. # The webapp is stopped, but it is not undeployed. [o3@tomcat-r8 cockpit]$ wget -O - -q --http-user=tomcat --http-password=tomcat http://localhost:8080/manager/text/list|sed 1d /manager:running:9:/usr/share/tomcat7/webapps/manager /cockpit:stopped:0:cockpit # Listing the contents of $CATALINA_HOME/webapps, we see that the tree is still # there: [o3@tomcat-r8 cockpit]$ ls /var/lib/o3/tomcat/installs cockpit The documentation states: WARNING - This command will delete any web application artifacts that exist within appBase directory (typically "webapps") for this virtual host. This will delete the the application .WAR, if present, the application directory resulting either from a deploy in unpacked form or from .WAR expansion as well as the XML Context definition from $CATALINA_BASE/conf/[enginename]/[hostname]/ directory. This turns out to be false in this case. While the application is stopped, the web application artifacts are NOT removed. The undeploy command should have failed with, say "FAIL - context was stopped but some articats remain, check access rights". What's more, the logs don't mention that the webapp tree has failed to be removed at all. If I chown back the webapp tree to its rightful owner, then the webapp is indeed undeployed as intended: all artifacts are destroyed. The culprit code seems to be at org/apache/catalina/manager/ManagerServlet.java, methods undeploy() and undeployDir(). Both use the .delete() method of File objects, but fail to check their return code. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: svn commit: r1085764 - in /tomcat/trunk/webapps/docs: project.xml windows-auth-howto.xml
On 27/03/2011 23:10, Konstantin Kolinko wrote: > 2011/3/26 : >> Author: markt >> Date: Sat Mar 26 16:45:26 2011 >> New Revision: 1085764 >> >> URL: http://svn.apache.org/viewvc?rev=1085764&view=rev >> Log: >> Add some Windows authentication notes to the docs >> >> Added: >>tomcat/trunk/webapps/docs/windows-auth-howto.xml (with props) >> Modified: >>tomcat/trunk/webapps/docs/project.xml >> > >> --- tomcat/trunk/webapps/docs/windows-auth-howto.xml (added) >> +++ tomcat/trunk/webapps/docs/windows-auth-howto.xml Sat Mar 26 16:45:26 2011 > >> +Built-in Tomcat support (work in progress, not yet available). > >> + >> +TBD. >> + > > Is it indeed work in progress or a WONTFIX for now? It is a work in progress. I spent some time on this over the weekend and made some progress but I'm waiting for some more information on bug 48685 which should hopefully allow me to make quicker progress. I'm aiming to get something that works - even if it is in an initial state and needs more work - in the next 7.0.x release. >> + >> + >> + >> + Full details of this solution can be found on the >> + http://waffle.codeplex.com/";>Waffle site. The edited >> highlights >> + are: > > What does "edited highlights" phrase mean? I do not understand the > word "edited" here. It is intended to show that only a very brief (i.e. edited) amount of information is shown. It could be replaced with "key features" if you think that would be clearer. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Mark's r906443
On 27/03/2011 23:50, Konstantin Kolinko wrote: > In > http://svn.apache.org/viewvc?view=revision&revision=906443 > > the description of CVE-2009-2901 was updated to say that it only > affects Windows platforms. > > There might be reasons why deploy may fail on unixes as well (e.g. > full disk). The patch to ExpandWar.expand() handles that case as well. The title is wrong there. It should be: Low: Insecure partial deploy after failed *un*deploy That does only affect Windows. I'll get the title fixed. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1086148 - in /tomcat/site/trunk: docs/security-5.html docs/security-6.html xdocs/security-5.xml xdocs/security-6.xml
Author: markt Date: Mon Mar 28 08:13:27 2011 New Revision: 1086148 URL: http://svn.apache.org/viewvc?rev=1086148&view=rev Log: Correct issue title Modified: tomcat/site/trunk/docs/security-5.html tomcat/site/trunk/docs/security-6.html tomcat/site/trunk/xdocs/security-5.xml tomcat/site/trunk/xdocs/security-6.xml Modified: tomcat/site/trunk/docs/security-5.html URL: http://svn.apache.org/viewvc/tomcat/site/trunk/docs/security-5.html?rev=1086148&r1=1086147&r2=1086148&view=diff == --- tomcat/site/trunk/docs/security-5.html (original) +++ tomcat/site/trunk/docs/security-5.html Mon Mar 28 08:13:27 2011 @@ -523,7 +523,7 @@ Affects: 5.5.0-5.5.28 -Low: Insecure partial deploy after failed deploy +Low: Insecure partial deploy after failed undeploy http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-2901";> CVE-2009-2901 Modified: tomcat/site/trunk/docs/security-6.html URL: http://svn.apache.org/viewvc/tomcat/site/trunk/docs/security-6.html?rev=1086148&r1=1086147&r2=1086148&view=diff == --- tomcat/site/trunk/docs/security-6.html (original) +++ tomcat/site/trunk/docs/security-6.html Mon Mar 28 08:13:27 2011 @@ -593,7 +593,7 @@ Affects: 6.0.0-6.0.20 -Low: Insecure partial deploy after failed deploy +Low: Insecure partial deploy after failed undeploy http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-2901";> CVE-2009-2901 Modified: tomcat/site/trunk/xdocs/security-5.xml URL: http://svn.apache.org/viewvc/tomcat/site/trunk/xdocs/security-5.xml?rev=1086148&r1=1086147&r2=1086148&view=diff == --- tomcat/site/trunk/xdocs/security-5.xml (original) +++ tomcat/site/trunk/xdocs/security-5.xml Mon Mar 28 08:13:27 2011 @@ -163,7 +163,7 @@ Affects: 5.5.0-5.5.28 -Low: Insecure partial deploy after failed deploy +Low: Insecure partial deploy after failed undeploy http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-2901";> CVE-2009-2901 Modified: tomcat/site/trunk/xdocs/security-6.xml URL: http://svn.apache.org/viewvc/tomcat/site/trunk/xdocs/security-6.xml?rev=1086148&r1=1086147&r2=1086148&view=diff == --- tomcat/site/trunk/xdocs/security-6.xml (original) +++ tomcat/site/trunk/xdocs/security-6.xml Mon Mar 28 08:13:27 2011 @@ -202,7 +202,7 @@ Affects: 6.0.0-6.0.20 -Low: Insecure partial deploy after failed deploy +Low: Insecure partial deploy after failed undeploy http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-2901";> CVE-2009-2901 - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 50983] IE 7 & 8 issues with docx and xlsx file extention
https://issues.apache.org/bugzilla/show_bug.cgi?id=50983 Mark Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Comment #1 from Mark Thomas 2011-03-28 04:15:13 EDT --- Bugzilla is not a support forum. Please use the users mailing list. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 50984] Manager application fails to report stranded artifacts when undeploying
https://issues.apache.org/bugzilla/show_bug.cgi?id=50984 Mark Thomas changed: What|Removed |Added Version|7.0.10 |7.0.11 --- Comment #1 from Mark Thomas 2011-03-28 04:16:20 EDT --- Version added to database and issue updated. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 47679] Not all headers get passed to Tomcat server from isapi_redirect.dll
https://issues.apache.org/bugzilla/show_bug.cgi?id=47679 --- Comment #3 from Mark Thomas 2011-03-28 04:25:56 EDT --- Report on users list of similar issues on windows 2k8/ IIS 7.5: http://markmail.org/message/obnvxffoc4wwy2x4 -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 48685] Spnego Support in Tomcat
https://issues.apache.org/bugzilla/show_bug.cgi?id=48685 --- Comment #26 from Michael Osipov <1983-01...@gmx.net> 2011-03-28 04:40:34 EDT --- Mark, here's what you need to make it run: I expect you/someone to have an already working AD environment where the server with tomcat running is registered in the domain, have an SPN set and an keytab created for that service account. This is what you need to configure your setenv.sh: KERBEROS_CONFIG="-Djava.security.auth.login.config=$CATALINA_HOME/conf/jaas.conf -Djavax.security.auth.useSubjectCredsOnly=false -Djava.security.krb5.conf=/etc/krb5.conf" The jaas.conf contains the login module pointing to the keytab or a already preloaded ticket cache. The krb5.conf is Unix usual with you realm and other realms used with tomcat. Pass KERBEROS_CONFIG to your JAVA_OPTS and make it run. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1086158 - /tomcat/trunk/webapps/docs/windows-auth-howto.xml
Author: markt Date: Mon Mar 28 08:49:49 2011 New Revision: 1086158 URL: http://svn.apache.org/viewvc?rev=1086158&view=rev Log: Update based on feedback Fix typos Modified: tomcat/trunk/webapps/docs/windows-auth-howto.xml Modified: tomcat/trunk/webapps/docs/windows-auth-howto.xml URL: http://svn.apache.org/viewvc/tomcat/trunk/webapps/docs/windows-auth-howto.xml?rev=1086158&r1=1086157&r2=1086158&view=diff == --- tomcat/trunk/webapps/docs/windows-auth-howto.xml (original) +++ tomcat/trunk/webapps/docs/windows-auth-howto.xml Mon Mar 28 08:49:49 2011 @@ -35,7 +35,7 @@ Integrated Windows authentication is most frequently used within intranet environments since it requires that the server performing the authentication and -the user being authentication are part of the same domain. For the user to be +the user being authenticated are part of the same domain. For the user to be authenticated automatically, the client machine used by the user must also be part of the domain. There are several options for implementing integrated Windows authentication @@ -57,17 +57,28 @@ sections. - Full details of this solution can be found on the - http://waffle.codeplex.com/";>Waffle site. The edited highlights - are: + Full details of this solution can be found through the + http://waffle.codeplex.com/";>Waffle site. The key features are: Drop-in solution Simple configuration (no JAAS or Kerberos keytab configuration required) + Uses a native library + + Full details of this solution can be found through the + http://static.springsource.org/spring-security/site/extensions/krb/index.html";> + Kerberos extension site. The key features are: + + Extension to Spring Security + Requires a Kerberos keytab file to be generated + Pure Java solution + + + @@ -92,11 +103,11 @@ sections. there are a number of third-party modules that can be used. These include: http://sourceforge.net/projects/mod-auth-sspi/";>mod_auth_sspi - for use on Windows platforms - http://modntlm.sourceforge.net/";>mod_ntlm for non-Windows - platforms (NTLM v1 only) + for use on Windows platforms. http://adldap.sourceforge.net/wiki/doku.php?id=mod_auth_ntlm_winbind";> - mod_auth_ntlm_winbind for non-Windows platforms (NTLM v2) + mod_auth_ntlm_winbind for non-Windows platforms. Known to work with httpd + 2.0.x on 32-bit platforms. Some users have reported stability issues with both + httpd 2.2.x builds and 64-bit Linux builds. There are three steps to configuring httpd to provide Windows authentication. They are: - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 12428] request.getUserPrincipal(): Misinterpretation of specification?
https://issues.apache.org/bugzilla/show_bug.cgi?id=12428 Mark Thomas changed: What|Removed |Added Component|Catalina|Catalina Version|Nightly Build |trunk Product|Tomcat 4|Tomcat 7 --- Comment #28 from Mark Thomas 2011-03-28 06:11:46 EDT --- Since this is the last open Tomcat 4 bug and a) I would like to make the Tomcat 4 bugs read-only and b) any changes as a result of this bug will be in Tomcat 7 onwards, I am moving this issue to Tomcat 7. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Tomcat7.sh example script
Hi, Commons-daemon that goes with Tomcat 7.0.11 includes Tomcat7.sh init.d example script. Out-of-the box, that script runs on default JVM, which is for 32-bit Sun Java equal to 'Client' JVM. I assume that starting tomcat on 'Server' JVM is generally better then 'Client' JVM. What do you think about adding '$JSVC_JVM' into run, start and version actions of that script? Then, user could add e.g. "export JSVC_JVM='-jvm server'" into setenv.sh to use appropriate JVM, without need to modify the example script. I also believe that it would be nice to add just one short startup/shutdown message into the same script (e.g. "Starting tomcat... [OK]"). What do you think? -Ognjen - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 50872] Intermittent SSL failure - client certificate not found
https://issues.apache.org/bugzilla/show_bug.cgi?id=50872 Clive Nicholson changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID | --- Comment #4 from Clive Nicholson 2011-03-28 07:41:20 EDT --- Sorry to re-open this call but after enabling SSL debugging it appears that Tomcat only ever uses the key store specified (if any) in the first SSL connection. Once the key store has initially been set, setting the 'javax.net.ssl.keyStore' and the 'javax.net.ssl.keyStorePassword' system properties in web applications does not affect the key store that is used even though the system properties appear to have been changed (i.e printing out the Java system properties shows the amended values but certificates in these key stores are not found). Is it recommended to add parameters similar to the ones below to the Tomcat startup to define the default keystore or should Tomcat be recognising the change to the Java system properties? -Djavax.net.ssl.keyStore=*** -Djavax.net.ssl.keyStorePassword=** -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 50872] Intermittent SSL failure - client certificate not found
https://issues.apache.org/bugzilla/show_bug.cgi?id=50872 Mark Thomas changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||INVALID --- Comment #5 from Mark Thomas 2011-03-28 07:51:31 EDT --- Again, this belongs on the users mailing list. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 48685] Spnego Support in Tomcat
https://issues.apache.org/bugzilla/show_bug.cgi?id=48685 --- Comment #27 from Mark Thomas 2011-03-28 08:01:05 EDT --- I'd managed to work out the system properties. I currently suspect issues with my jaas.conf and/or krb5.conf or possibly the keytab file. Samples of those would help although I am currently considering aiming for a Spring Security style solution since that appears to only requires the keytab file (although I haven't looked at that in detail yet). -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Bugzilla and Tomcat 3/4
There are no open issues in either of these projects. Since development has essentially ceased, I made these read-only today. This can always be reverted if someone gets an itch to start work on those versions. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1086201 - in /tomcat/trunk: java/org/apache/coyote/http11/Constants.java test/org/apache/coyote/http11/TestGzipOutputFilter.java
Author: markt
Date: Mon Mar 28 12:09:24 2011
New Revision: 1086201
URL: http://svn.apache.org/viewvc?rev=1086201&view=rev
Log:
Remove constant only used by tests
Modified:
tomcat/trunk/java/org/apache/coyote/http11/Constants.java
tomcat/trunk/test/org/apache/coyote/http11/TestGzipOutputFilter.java
Modified: tomcat/trunk/java/org/apache/coyote/http11/Constants.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/coyote/http11/Constants.java?rev=1086201&r1=1086200&r2=1086201&view=diff
==
--- tomcat/trunk/java/org/apache/coyote/http11/Constants.java (original)
+++ tomcat/trunk/java/org/apache/coyote/http11/Constants.java Mon Mar 28
12:09:24 2011
@@ -120,12 +120,6 @@ public final class Constants {
public static final byte LC_OFFSET = A - a;
-/**
- * Default HTTP header buffer size.
- */
-public static final int DEFAULT_HTTP_HEADER_BUFFER_SIZE = 48 * 1024;
-
-
/* Various constant "strings" */
public static final String CONNECTION = "Connection";
public static final String CLOSE = "close";
Modified: tomcat/trunk/test/org/apache/coyote/http11/TestGzipOutputFilter.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/test/org/apache/coyote/http11/TestGzipOutputFilter.java?rev=1086201&r1=1086200&r2=1086201&view=diff
==
--- tomcat/trunk/test/org/apache/coyote/http11/TestGzipOutputFilter.java
(original)
+++ tomcat/trunk/test/org/apache/coyote/http11/TestGzipOutputFilter.java Mon
Mar 28 12:09:24 2011
@@ -49,8 +49,7 @@ public class TestGzipOutputFilter extend
public void testFlushingWithGzip() throws Exception {
// set up response, InternalOutputBuffer, and ByteArrayOutputStream
Response res = new Response();
-InternalOutputBuffer iob = new InternalOutputBuffer(res,
-Constants.DEFAULT_HTTP_HEADER_BUFFER_SIZE);
+InternalOutputBuffer iob = new InternalOutputBuffer(res, 8 * 1024);
ByteArrayOutputStream bos = new ByteArrayOutputStream();
iob.setOutputStream(bos);
res.setOutputBuffer(iob);
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1086203 - in /tomcat/trunk/java/org/apache/coyote/http11: Http11NioProcessor.java InternalAprOutputBuffer.java InternalNioOutputBuffer.java InternalOutputBuffer.java
Author: markt
Date: Mon Mar 28 12:16:47 2011
New Revision: 1086203
URL: http://svn.apache.org/viewvc?rev=1086203&view=rev
Log:
Remove unused code
Modified:
tomcat/trunk/java/org/apache/coyote/http11/Http11NioProcessor.java
tomcat/trunk/java/org/apache/coyote/http11/InternalAprOutputBuffer.java
tomcat/trunk/java/org/apache/coyote/http11/InternalNioOutputBuffer.java
tomcat/trunk/java/org/apache/coyote/http11/InternalOutputBuffer.java
Modified: tomcat/trunk/java/org/apache/coyote/http11/Http11NioProcessor.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/coyote/http11/Http11NioProcessor.java?rev=1086203&r1=1086202&r2=1086203&view=diff
==
--- tomcat/trunk/java/org/apache/coyote/http11/Http11NioProcessor.java
(original)
+++ tomcat/trunk/java/org/apache/coyote/http11/Http11NioProcessor.java Mon Mar
28 12:16:47 2011
@@ -707,12 +707,6 @@ public class Http11NioProcessor extends
}
-// -- Connector Methods
-
-public SSLSupport getSslSupport() {
-return sslSupport;
-}
-
// -- Protected Methods
Modified:
tomcat/trunk/java/org/apache/coyote/http11/InternalAprOutputBuffer.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/coyote/http11/InternalAprOutputBuffer.java?rev=1086203&r1=1086202&r2=1086203&view=diff
==
--- tomcat/trunk/java/org/apache/coyote/http11/InternalAprOutputBuffer.java
(original)
+++ tomcat/trunk/java/org/apache/coyote/http11/InternalAprOutputBuffer.java Mon
Mar 28 12:16:47 2011
@@ -93,14 +93,6 @@ public class InternalAprOutputBuffer ext
}
-/**
- * Get the underlying socket input stream.
- */
-public long getSocket() {
-return socket;
-}
-
-
// - Public Methods
Modified:
tomcat/trunk/java/org/apache/coyote/http11/InternalNioOutputBuffer.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/coyote/http11/InternalNioOutputBuffer.java?rev=1086203&r1=1086202&r2=1086203&view=diff
==
--- tomcat/trunk/java/org/apache/coyote/http11/InternalNioOutputBuffer.java
(original)
+++ tomcat/trunk/java/org/apache/coyote/http11/InternalNioOutputBuffer.java Mon
Mar 28 12:16:47 2011
@@ -91,13 +91,6 @@ public class InternalNioOutputBuffer ext
this.socket = socket;
}
-/**
- * Get the underlying socket input stream.
- */
-public NioChannel getSocket() {
-return socket;
-}
-
public void setSelectorPool(NioSelectorPool pool) {
this.pool = pool;
}
@@ -151,9 +144,6 @@ public class InternalNioOutputBuffer ext
flushBuffer();
}
-public boolean isWritable() {
-return lastWrite.get()>0;
-}
// HTTP/1.1 Output Methods
Modified: tomcat/trunk/java/org/apache/coyote/http11/InternalOutputBuffer.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/coyote/http11/InternalOutputBuffer.java?rev=1086203&r1=1086202&r2=1086203&view=diff
==
--- tomcat/trunk/java/org/apache/coyote/http11/InternalOutputBuffer.java
(original)
+++ tomcat/trunk/java/org/apache/coyote/http11/InternalOutputBuffer.java Mon
Mar 28 12:16:47 2011
@@ -88,16 +88,6 @@ public class InternalOutputBuffer extend
/**
- * Get the underlying socket output stream.
- */
-public OutputStream getOutputStream() {
-
-return outputStream;
-
-}
-
-
-/**
* Set the socket buffer size.
*/
public void setSocketBuffer(int socketBufferSize) {
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 50957] Blocking IO can serve wrong response data
https://issues.apache.org/bugzilla/show_bug.cgi?id=50957 --- Comment #9 from Brad Plies 2011-03-28 14:44:59 EDT --- Brainstorming out loud after examining some Tomcat code... In the witnessed case of receiving ImageA.gif as ImageB.gif, this suggests that the same InternalOutputBuffer was re-used to respond to both requests. This could hypothetically be possible if the output buffer were not properly reset between requests. Http11Processor.process(socket) AbstractOutputBuffer.nextRequest() will call response.recycle() that will reset the contentType, status, headers, encoding, etc. Most of these recycling/resetting operations are guarded by !isAsync() (AsyncStateMachine) I wonder if there is a concurrency hazard surrounding isAsync()? Namely that isAsync accesses shared state and is, itself, not synchronized. So couldn't you have, due to unlucky timing, a dirty read where: isAsync() returns true but almost immediately becomes false or isAsync() returns false but almost immediately becomes true While all of the async state mutating methods are synchronized, an unsynchronized read is governing control flow of external code. It should be possible for the state to be written concurrently with the unsync read and perhaps cause an unanticipated code path to execute. Http11Processor.process(socket) calls isAsync() 4 times (swallowInput(), endRequest(), buffers.nextRequest(), & SocketState.LONG) and could all conceivably return different answers from call to call. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 50957] Blocking IO can serve wrong response data
https://issues.apache.org/bugzilla/show_bug.cgi?id=50957 --- Comment #10 from Mark Thomas 2011-03-28 15:04:59 EDT --- I have been looking at this as well. To address the isAsync() question I suspect that this is not the cause since: - the issue is with static content where async state is not changing - it doesn't explain why BIO is affected but NIO is not In the same way a failure to recycled an output buffer could cause this, so could not recycling an input buffer. I have been reviewing the code and for a single request there are multiple points where recycle is called. While I can find a error conditions where I can skip one of the recycle calls, I can't find a code path that would allow all of them to be skipped. I'll tighten up the areas I can find for 7.0.12 but without a clear idea of exactly how this issue is triggered I can't be sure that the issue will be fixed. If no further reports appear post 7.0.12 then that would suggest that the issue was fixed. I'm not exactly comfortable with that plan but barring a reproducible test case or an explanation of how the error occurs I don't have a better plan right now. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1086347 - /tomcat/trunk/java/org/apache/coyote/http11/Http11Processor.java
Author: markt
Date: Mon Mar 28 19:10:31 2011
New Revision: 1086347
URL: http://svn.apache.org/viewvc?rev=1086347&view=rev
Log:
Always recycle unless it is an async request.
Possible contributing factor to
https://issues.apache.org/bugzilla/show_bug.cgi?id=50957 ?
Modified:
tomcat/trunk/java/org/apache/coyote/http11/Http11Processor.java
Modified: tomcat/trunk/java/org/apache/coyote/http11/Http11Processor.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/coyote/http11/Http11Processor.java?rev=1086347&r1=1086346&r2=1086347&view=diff
==
--- tomcat/trunk/java/org/apache/coyote/http11/Http11Processor.java (original)
+++ tomcat/trunk/java/org/apache/coyote/http11/Http11Processor.java Mon Mar 28
19:10:31 2011
@@ -326,8 +326,8 @@ public class Http11Processor extends Abs
} else if (isAsync()) {
return SocketState.LONG;
} else {
+recycle();
if (!keepAlive) {
-recycle();
return SocketState.CLOSED;
} else {
return SocketState.OPEN;
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1086349 - in /tomcat/trunk/java/org/apache/coyote: ajp/ http11/
Author: markt
Date: Mon Mar 28 19:15:06 2011
New Revision: 1086349
URL: http://svn.apache.org/viewvc?rev=1086349&view=rev
Log:
Move the processor.recycle calls to just before the point where the processor
is returned to the pool. This ensures returned processors are recycled (this
could have been skipped on some exception paths)
Possible contributing factor to
https://issues.apache.org/bugzilla/show_bug.cgi?id=50957 ?
Modified:
tomcat/trunk/java/org/apache/coyote/ajp/AjpAprProcessor.java
tomcat/trunk/java/org/apache/coyote/ajp/AjpAprProtocol.java
tomcat/trunk/java/org/apache/coyote/ajp/AjpProcessor.java
tomcat/trunk/java/org/apache/coyote/ajp/AjpProtocol.java
tomcat/trunk/java/org/apache/coyote/http11/Http11AprProcessor.java
tomcat/trunk/java/org/apache/coyote/http11/Http11AprProtocol.java
tomcat/trunk/java/org/apache/coyote/http11/Http11NioProcessor.java
tomcat/trunk/java/org/apache/coyote/http11/Http11Processor.java
tomcat/trunk/java/org/apache/coyote/http11/Http11Protocol.java
Modified: tomcat/trunk/java/org/apache/coyote/ajp/AjpAprProcessor.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/coyote/ajp/AjpAprProcessor.java?rev=1086349&r1=1086348&r2=1086349&view=diff
==
--- tomcat/trunk/java/org/apache/coyote/ajp/AjpAprProcessor.java (original)
+++ tomcat/trunk/java/org/apache/coyote/ajp/AjpAprProcessor.java Mon Mar 28
19:15:06 2011
@@ -316,7 +316,6 @@ public class AjpAprProcessor extends Abs
rp.setStage(org.apache.coyote.Constants.STAGE_KEEPALIVE);
recycle();
-
}
// Add the socket to the poller
@@ -329,12 +328,10 @@ public class AjpAprProcessor extends Abs
rp.setStage(org.apache.coyote.Constants.STAGE_ENDED);
if (error || endpoint.isPaused()) {
-recycle();
return SocketState.CLOSED;
} else if (isAsync()) {
return SocketState.LONG;
} else {
-recycle();
return SocketState.OPEN;
}
}
@@ -369,14 +366,12 @@ public class AjpAprProcessor extends Abs
if (isAsync()) {
if (error) {
request.updateCounters();
-recycle();
return SocketState.CLOSED;
} else {
return SocketState.LONG;
}
} else {
request.updateCounters();
-recycle();
if (error) {
return SocketState.CLOSED;
} else {
Modified: tomcat/trunk/java/org/apache/coyote/ajp/AjpAprProtocol.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/coyote/ajp/AjpAprProtocol.java?rev=1086349&r1=1086348&r2=1086349&view=diff
==
--- tomcat/trunk/java/org/apache/coyote/ajp/AjpAprProtocol.java (original)
+++ tomcat/trunk/java/org/apache/coyote/ajp/AjpAprProtocol.java Mon Mar 28
19:15:06 2011
@@ -197,6 +197,7 @@ public class AjpAprProtocol extends Abst
connections.put(socket, processor);
socket.setAsync(true);
} else {
+processor.recycle();
recycledProcessors.offer(processor);
}
return state;
@@ -220,6 +221,7 @@ public class AjpAprProtocol extends Abst
// less-than-verbose logs.
log.error(sm.getString("ajpprotocol.proto.error"), e);
}
+processor.recycle();
recycledProcessors.offer(processor);
return SocketState.CLOSED;
}
@@ -251,6 +253,7 @@ public class AjpAprProtocol extends Abst
}
if (state != SocketState.LONG && state !=
SocketState.ASYNC_END) {
connections.remove(socket);
+processor.recycle();
recycledProcessors.offer(processor);
if (state == SocketState.OPEN) {
((AprEndpoint)proto.endpoint).getPoller().add(socket.getSocket().longValue());
Modified: tomcat/trunk/java/org/apache/coyote/ajp/AjpProcessor.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/coyote/ajp/AjpProcessor.java?rev=1086349&r1=1086348&r2=1086349&view=diff
==
--- tomcat/trunk/java/org/apache/coyote/ajp/AjpProcessor.java (original)
+++ tomcat/trunk/java/org/apache/coyote/ajp/AjpProcessor.java Mon Mar 28
19:15:06 2011
@@ -334,7 +334,6 @@ public class AjpProcessor extends Abstra
rp.setStage(org.apache.coyote.Constants.STAGE_KEEPALIVE);
recycle();
-
}
rp.setStage(org.apache.coyote.Constants.STAGE_ENDED);
@@ -342,7 +341,6 @@ public class AjpProcessor extends Abstra
if (isAsync() &
svn commit: r1086352 - in /tomcat/trunk/java/org/apache/catalina/connector: CoyoteAdapter.java LocalStrings.properties
Author: markt
Date: Mon Mar 28 19:19:23 2011
New Revision: 1086352
URL: http://svn.apache.org/viewvc?rev=1086352&view=rev
Log:
Protect against things going wrong during access logging. An un-handled
exception here could trigger some unexpected code paths.
Possible contributing factor to
https://issues.apache.org/bugzilla/show_bug.cgi?id=50957 ?
Modified:
tomcat/trunk/java/org/apache/catalina/connector/CoyoteAdapter.java
tomcat/trunk/java/org/apache/catalina/connector/LocalStrings.properties
Modified: tomcat/trunk/java/org/apache/catalina/connector/CoyoteAdapter.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/connector/CoyoteAdapter.java?rev=1086352&r1=1086351&r2=1086352&view=diff
==
--- tomcat/trunk/java/org/apache/catalina/connector/CoyoteAdapter.java
(original)
+++ tomcat/trunk/java/org/apache/catalina/connector/CoyoteAdapter.java Mon Mar
28 19:19:23 2011
@@ -482,8 +482,13 @@ public class CoyoteAdapter implements Ad
(connector.getURIEncoding());
}
-connector.getService().getContainer().logAccess(
-request, response, time, true);
+try {
+connector.getService().getContainer().logAccess(
+request, response, time, true);
+} catch (Throwable t) {
+ExceptionUtils.handleThrowable(t);
+log.warn(sm.getString("coyoteAdapter.accesslogFail"), t);
+}
if (create) {
request.recycle();
Modified:
tomcat/trunk/java/org/apache/catalina/connector/LocalStrings.properties
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/connector/LocalStrings.properties?rev=1086352&r1=1086351&r2=1086352&view=diff
==
--- tomcat/trunk/java/org/apache/catalina/connector/LocalStrings.properties
(original)
+++ tomcat/trunk/java/org/apache/catalina/connector/LocalStrings.properties Mon
Mar 28 19:19:23 2011
@@ -36,6 +36,7 @@ coyoteAdapter.service=An exception or er
coyoteAdapter.read=The servlet did not read all available bytes during the
processing of the read event
coyoteAdapter.parsePathParam=Unable to parse the path parameters using
encoding [{0}]. The path parameters in the URL will be ignored.
coyoteAdapter.debug=The variable [{0}] has value [{1}]
+coyoteAdapter.accesslogFail=Exception while attempting to add an entry to the
access log
#
# CoyoteResponse
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 50957] Blocking IO can serve wrong response data
https://issues.apache.org/bugzilla/show_bug.cgi?id=50957 --- Comment #11 from Brad Plies 2011-03-28 15:33:18 EDT --- (In reply to comment #10) > To address the isAsync() question I suspect that this is not the cause since: > - the issue is with static content where async state is not changing Yes and no. Even though it is static content being swapped & duplicated, static content is not the only resource in the request stream. For instance ImageA.gif & ImageB.gif are included in a page that contains a number of dynamic JSP elements as well. In post #1 I listed a scenario where a JS file was served instead of HTML. In that case, the page was a dynamic JSP. > - it doesn't explain why BIO is affected but NIO is not If indeed BIO & NIO share nearly identical isAsync() logic and if the real problem is a concurrency hazard within that logic then the unlucky timing would just happen to be more likely in BIO. NIO Protocol has notably less isAsync() calls. So for all I know NIO is affected also, we just haven't noticed yet. Maybe it is a Bohrbug or Heisenbug :) Maybe someone with exceptionally strong concurrency skills can review isAsync() and its usage for safety. Either it is a hazard or it isn't. > In the same way a failure to recycled an output buffer could cause this, so > could not recycling an input buffer. I have been reviewing the code and for a > single request there are multiple points where recycle is called. While I can > find a error conditions where I can skip one of the recycle calls, I can't > find > a code path that would allow all of them to be skipped. Good point on input v.s. output. Yet aren't those input recycle calls governed by the same suspect guard? Perhaps it is not necessary to skip all recycle calls in order to cause the behavior. > I'll tighten up the areas I can find for 7.0.12 but without a clear idea of > exactly how this issue is triggered I can't be sure that the issue will be > fixed. If no further reports appear post 7.0.12 then that would suggest that > the issue was fixed. I'm not exactly comfortable with that plan but barring a > reproducible test case or an explanation of how the error occurs I don't have > a > better plan right now. I can respect that. Given how long Tomcat 7.0 has been GA before this report was submitted, I would not expect additional reports to be as forthcoming even if it still is a bug. At least you and others are aware of this report and might be able to match it to future reports. Hopefully someone else will be able to do a better job defining a reproducible test case. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 50957] Blocking IO can serve wrong response data
https://issues.apache.org/bugzilla/show_bug.cgi?id=50957 --- Comment #12 from Mark Thomas 2011-03-28 16:03:53 EDT --- (In reply to comment #11) > (In reply to comment #10) > > To address the isAsync() question I suspect that this is not the cause > > since: > > - the issue is with static content where async state is not changing > Yes and no. Even though it is static content being swapped & duplicated, > static content is not the only resource in the request stream. For instance > ImageA.gif & ImageB.gif are included in a page that contains a number of > dynamic JSP elements as well. > > In post #1 I listed a scenario where a JS file was served instead of HTML. In > that case, the page was a dynamic JSP. None of those requests use async processing. Unless you explicitly use Servlet 3.0 async APIs then isAsync() will always return false. > > - it doesn't explain why BIO is affected but NIO is not > If indeed BIO & NIO share nearly identical isAsync() logic and if the real > problem is a concurrency hazard within that logic then the unlucky timing > would > just happen to be more likely in BIO. NIO Protocol has notably less isAsync() > calls. So for all I know NIO is affected also, we just haven't noticed yet. > Maybe it is a Bohrbug or Heisenbug :) > > Maybe someone with exceptionally strong concurrency skills can review > isAsync() > and its usage for safety. Either it is a hazard or it isn't. At the moment, I'm happy isAsync() is safe. There were issues in the past (bug 49884) but the re-factoring that fixed that bug means that it should not be possible for one thread to be reading isAsync() whilst another is changing the value it returns. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 50957] Blocking IO can serve wrong response data
https://issues.apache.org/bugzilla/show_bug.cgi?id=50957 --- Comment #13 from Brad Plies 2011-03-28 16:42:53 EDT --- (In reply to comment #12) > None of those requests use async processing. Unless you explicitly use Servlet > 3.0 async APIs then isAsync() will always return false. In our application we are not explicitly using Servlet 3.0 async so the hypothesis that async() is suspicious in this case is invalid. So as far as deduction goes it one must backtrack to examining how buffers are used and pipelined requests are handled. > At the moment, I'm happy isAsync() is safe. There were issues in the past (bug > 49884) but the re-factoring that fixed that bug means that it should not be > possible for one thread to be reading isAsync() whilst another is changing the > value it returns. isAsync(), I see, uses volatile so maybe it is alright afterall. At least we've managed to deduce a few things that aren't the problem. Thanks for helping. I'll take a look at anything that gets committed and will at least try to run a recent build w/ BIO in an alternate environment. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 50975] IIS connector times out on Transfer Encoded content, never sending the chunked content
https://issues.apache.org/bugzilla/show_bug.cgi?id=50975 --- Comment #1 from Aaron Johnson 2011-03-28 18:05:44 EDT --- Created an attachment (id=26808) --> (https://issues.apache.org/bugzilla/attachment.cgi?id=26808) Don't send content type for chunked content >From what I can tell, in the case of chunking, the headers are sent first then the chunked content. What seems to be happening is that when both Transfer-Encoding=chunked and content-type= set the connector endpoint never requests the body because it still thinks there is content in the message. This fix simply removes the content-type field if transfer-encoding=chunked or content > 4GB -- basically just moving the logic around. I tried to figure out what part of IIS is setting the content-type, but never came to any conclusions. Is there any way to get a 64-bit built binary to test out these changes for a customer -- I only had the ability to build a 32-bit binary? -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 50975] IIS connector times out on Transfer Encoded content, never sending the chunked content
https://issues.apache.org/bugzilla/show_bug.cgi?id=50975 Aaron Johnson changed: What|Removed |Added Attachment #26808|Don't send content type for |Don't send content length description|chunked content |for chunked content --- Comment #2 from Aaron Johnson 2011-03-28 18:07:35 EDT --- (From update of attachment 26808) I mistakenly referred to content type, when I should have said content-length in the comment above. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 50989] New: JSP causing memory leaks under high load, multi-version
https://issues.apache.org/bugzilla/show_bug.cgi?id=50989 Summary: JSP causing memory leaks under high load, multi-version Product: Tomcat 6 Version: 6.0.32 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Jasper AssignedTo: dev@tomcat.apache.org ReportedBy: an...@deontik.com Created an attachment (id=26809) --> (https://issues.apache.org/bugzilla/attachment.cgi?id=26809) Hello World JSP I've been setting up a scalable test bed for performance and scalability testing of some Java web applications. To establish basic some benchmarks, I've used a simple "Hello World" JSP (attached) with no tags or dynamic content. This JSP consistently leaks memory on multiple Java platforms and on different versions of Tomcat, eventually resulting in an OutOfMemory exception. If I use an equivalent Java servlet (also attached), no such exceptions occur. Platforms tested: Linux 2.6.32 32-bit i586 (Ubuntu 10.4) + Java 6u24 + Tomcat 6.0.32 Linux 2.6.32 32-bit i586 (Ubuntu 10.4) + Java 6u24 + Tomcat 6.0.29 Linux 2.6.32 32-bit i586 (Ubuntu 10.4) + Java 6u24 + Tomcat 5.5.33 Mac OS X 10.6.7, 64-bit Intel i7 (quad core, iMac) + Java 1.6.0_24 + Tomcat 6.0.24 The linux tests were done in VMWare with varying memory configurations for both the VM image and the JVM. Most-used config was 768MB VM with -Xmx512MB for the JVM. The Mac OS X tests were done on a JVM with -Xmx2GB. Tests were driven by either Grinder or apache bench (ab) using 5-10 active workers. For the -Xmx512MB configuration, a memory error occurs after roughly 250,000 requests. Note that the JSP starts to "stutter" somewhat earlier, I assume due to garbage collection overheads as the memory limit approaches. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 50989] JSP causing memory leaks under high load, multi-version
https://issues.apache.org/bugzilla/show_bug.cgi?id=50989 --- Comment #1 from an...@deontik.com 2011-03-29 01:27:57 EDT --- Created an attachment (id=26810) --> (https://issues.apache.org/bugzilla/attachment.cgi?id=26810) Simple Hello World servlet for comparison with JSP (does not cause memory leaks) -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
