DO NOT REPLY [Bug 50819] New: Standard context is stopped BEFORE requesting session serialization
https://issues.apache.org/bugzilla/show_bug.cgi?id=50819 Summary: Standard context is stopped BEFORE requesting session serialization Product: Tomcat 6 Version: 6.0.32 Platform: PC OS/Version: All Status: NEW Severity: major Priority: P2 Component: Catalina AssignedTo: dev@tomcat.apache.org ReportedBy: segfaultma...@gmail.com When stopping the serveur, the Standard context is stopped which cause a destroy call on servlet, and after, the session serialization code is called. If the Servlet clean his session on the destroy call, well, at serialization time, there is no more session to serialize. The problem is in StandardContext.stop() - it destroys the filter at line 4869 and later at line 4875 it tries to serialize the data. You can see the effect of this operation order and more information here : https://issues.apache.org/jira/browse/WICKET-3470 (I first reported the problem to wicket team). -- 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: Reaching ulimit values for open files can generate huge log files
On 21/02/2011 17:33, Tim Funk wrote: > Do you want to limit the try/catch scope to just > serverSocketFactory.acceptSocket since setSocketOptions() can also throw > IOException? A couple of people have mentioned this and while the current code would be OK with a broader try/catch I like the idea of a limited try/catch since that makes it obvious what the code is doing. > Is there a case where a client can induce an exception while > setSocketOptions() is processing? I don't think so but let's not give them the opportunity. In terms of making this configurable, I'm minded not to initially. We can always add configuration options if users request them later. Mark > > > -Tim > > On 2/21/2011 10:21 AM, Mark Thomas wrote: >> The ASF Sonar installation managed to generate 46GB of identical log >> messages [1] today in the 8 hours it took to notice it was down. >> >> While better monitoring would/should have identified the problem sooner, >> it does demonstrate a problem with the acceptor threads in all three >> endpoints. If there is a system-level issue that causes the accept() >> call to always fail (such as hitting the ulimit) then the endpoint >> essentially enters a loop where it logs an error message for every >> iteration of the loop. This will result in many log messages per second. >> >> I'd like to do something about this. I was thinking of something along >> the lines of the following for each endpoint. > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 50820] New: Unable to stop tomcat.
https://issues.apache.org/bugzilla/show_bug.cgi?id=50820 Summary: Unable to stop tomcat. Product: Tomcat 6 Version: 6.0.28 Platform: PC OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: Catalina AssignedTo: dev@tomcat.apache.org ReportedBy: kni...@nhn.com I have running nexus web application server (sonatype corp) on tomcat. To I tried to stop tomcat, I executed "bin/catalina.sh stop". It seemed that it would work. As a result, I could not connect tomcat. But tomcat daemon was alive for 20 minutes like below. # ps -ef | grep java root 1398 1 7 20:01 pts/200:00:24 /usr/local/j2se/bin/java -Djava.util.logging.config.file=/usr/local/tomcat6/conf/logging.properties -Xms1000m -Xmx1000m -XX:+UseParallelGC -XX:+UseParallelOldGC -XX:+DisableExplicitGC -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -Djava.endorsed.dirs=/usr/local/tomcat6/endorsed -classpath /usr/local/tomcat6/bin/bootstrap.jar -Dcatalina.base=/usr/local/tomcat6 -Dcatalina.home=/usr/local/tomcat6 -Djava.io.tmpdir=/usr/local/tomcat6/temp org.apache.catalina.startup.Bootstrap start So, I generated thread dump like below. # /usr/local/j2se/bin/jstack -F -l 1398 > 2012.txt Attaching to process ID 1398, please wait... Debugger attached successfully. Server compiler detected. JVM version is 19.1-b02 Finding object size using Printezis bits and skipping over... Finding object size using Printezis bits and skipping over... Finding object size using Printezis bits and skipping over... Finding object size using Printezis bits and skipping over... Finding object size using Printezis bits and skipping over... Finding object size using Printezis bits and skipping over... Finding object size using Printezis bits and skipping over... Finding object size using Printezis bits and skipping over... Finding object size using Printezis bits and skipping over... Finding object size using Printezis bits and skipping over... Finding object size using Printezis bits and skipping over... Finding object size using Printezis bits and skipping over... Finding object size using Printezis bits and skipping over... Finding object size using Printezis bits and skipping over... Finding object size using Printezis bits and skipping over... Finding object size using Printezis bits and skipping over... Finding object size using Printezis bits and skipping over... Finding object size using Printezis bits and skipping over... Finding object size using Printezis bits and skipping over... # after 5 minutes, I runned "thread dump". The content of two thread dump is equal. So. I added an attachement of thread dump. There are pattern of thread in thread dump like below Thread 1465: (state = BLOCKED) - java.lang.Object.wait(long) @bci=0 (Interpreted frame) - java.lang.Object.wait() @bci=2, line=485 (Interpreted frame) - org.apache.tomcat.util.net.JIoEndpoint$Worker.await() @bci=8, line=458 (Interpreted frame) - org.apache.tomcat.util.net.JIoEndpoint$Worker.run() @bci=11, line=484 (Interpreted frame) - java.lang.Thread.run() @bci=11, line=662 (Interpreted frame) Locked ownable synchronizers: - None Thread 1428: (state = BLOCKED) - sun.misc.Unsafe.park(boolean, long) @bci=0 (Interpreted frame) - java.util.concurrent.locks.LockSupport.parkNanos(java.lang.Object, long) @bci=20, line=198 (Interpreted frame) - java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(long) @bci=68, line=2025 (Interpreted frame) - java.util.concurrent.DelayQueue.take() @bci=57, line=164 (Interpreted frame) - java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take() @bci=4, line=609 (Interpreted frame) - java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take() @bci=1, line=602 (Interpreted frame) - java.util.concurrent.ThreadPoolExecutor.getTask() @bci=78, line=947 (Interpreted frame) - java.util.concurrent.ThreadPoolExecutor$Worker.run() @bci=18, line=907 (Interpreted frame) - java.lang.Thread.run() @bci=11, line=662 (Interpreted frame) Locked ownable synchronizers: - None Thread 1415: (state = BLOCKED) - java.lang.Object.wait(long) @bci=0 (Interpreted frame) - java.lang.ref.ReferenceQueue.remove(long) @bci=44, line=118 (Interpreted frame) - java.lang.ref.ReferenceQueue.remove() @bci=2, line=134 (Interpreted frame) - java.lang.ref.Finalizer$FinalizerThread.run() @bci=3, line=159 (Interpreted frame) * My Environment jdk : 1.6.0_24 Tomcat : 6.0.28 linux : CentOS release 5.3 (Final) # netstat -anp | grep java unix 2 [ ACC ] STREAM LISTENING 90571504 1398/java /usr/local/tomcat6/temp/.java_pid1398.tmp I tried netstat -anp and tomcat port is not listed there but still I am unable to start the service. So, I had to kill by using "kill" command. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email ---
DO NOT REPLY [Bug 50820] Unable to stop tomcat.
https://issues.apache.org/bugzilla/show_bug.cgi?id=50820 Mark Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Comment #1 from Mark Thomas 2011-02-23 06:36:13 EST --- This question belongs on the users 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
Re: Reaching ulimit values for open files can generate huge log files
Sorry - I meant to say - since the existing setSocketOptions() is in the try/catch block as accept(). Is it possible for a network client to send an ip packet to cause a failure and throw a SocketException while internally tomcat is setting each of the socket options? So the net effect is - the errorDelay value is set causing which makes endPoint fall asleep. Which could be a client induced DOS attack. So in the context above: user/client is someone on the network end, not the admin of the box. If the admin puts a config option in which causes setSocketOptions() to fail ... that is their problem. -Tim On 2/23/2011 5:48 AM, Mark Thomas wrote: On 21/02/2011 17:33, Tim Funk wrote: Do you want to limit the try/catch scope to just serverSocketFactory.acceptSocket since setSocketOptions() can also throw IOException? A couple of people have mentioned this and while the current code would be OK with a broader try/catch I like the idea of a limited try/catch since that makes it obvious what the code is doing. Is there a case where a client can induce an exception while setSocketOptions() is processing? I don't think so but let's not give them the opportunity. In terms of making this configurable, I'm minded not to initially. We can always add configuration options if users request them later. - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: Reaching ulimit values for open files can generate huge log files
On 23/02/2011 11:47, Tim Funk wrote: > Sorry - I meant to say - since the existing setSocketOptions() is in the > try/catch block as accept(). Is it possible for a network client to send > an ip packet to cause a failure and throw a SocketException while > internally tomcat is setting each of the socket options? So the net > effect is - the errorDelay value is set causing which makes endPoint > fall asleep. Which could be a client induced DOS attack. No problem, that is what I thought you meant :) Mark > > So in the context above: user/client is someone on the network end, not > the admin of the box. If the admin puts a config option in which causes > setSocketOptions() to fail ... that is their problem. > > -Tim > > > On 2/23/2011 5:48 AM, Mark Thomas wrote: >> On 21/02/2011 17:33, Tim Funk wrote: >>> Do you want to limit the try/catch scope to just >>> serverSocketFactory.acceptSocket since setSocketOptions() can also throw >>> IOException? >> >> A couple of people have mentioned this and while the current code would >> be OK with a broader try/catch I like the idea of a limited try/catch >> since that makes it obvious what the code is doing. >> >>> Is there a case where a client can induce an exception while >>> setSocketOptions() is processing? >> >> I don't think so but let's not give them the opportunity. >> >> In terms of making this configurable, I'm minded not to initially. We >> can always add configuration options if users request them later. > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1073711 - in /tomcat/trunk: java/org/apache/tomcat/util/net/ webapps/docs/
Author: markt
Date: Wed Feb 23 11:58:47 2011
New Revision: 1073711
URL: http://svn.apache.org/viewvc?rev=1073711&view=rev
Log:
Better handling in acceptor threads if server hits ulimit for open files
Modified:
tomcat/trunk/java/org/apache/tomcat/util/net/AbstractEndpoint.java
tomcat/trunk/java/org/apache/tomcat/util/net/AprEndpoint.java
tomcat/trunk/java/org/apache/tomcat/util/net/JIoEndpoint.java
tomcat/trunk/java/org/apache/tomcat/util/net/NioEndpoint.java
tomcat/trunk/webapps/docs/changelog.xml
Modified: tomcat/trunk/java/org/apache/tomcat/util/net/AbstractEndpoint.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/util/net/AbstractEndpoint.java?rev=1073711&r1=1073710&r2=1073711&view=diff
==
--- tomcat/trunk/java/org/apache/tomcat/util/net/AbstractEndpoint.java
(original)
+++ tomcat/trunk/java/org/apache/tomcat/util/net/AbstractEndpoint.java Wed Feb
23 11:58:47 2011
@@ -104,6 +104,9 @@ public abstract class AbstractEndpoint {
public static final String SSL_ATTR_ALLOW_UNSAFE_RENEG =
"allowUnsafeLegacyRenegotiation";
+private static final int INITIAL_ERROR_DELAY = 50;
+private static final int MAX_ERROR_DELAY = 1600;
+
// - Fields
@@ -614,7 +617,37 @@ public abstract class AbstractEndpoint {
} else return -1;
}
-
+/**
+ * Provides a common approach for sub-classes to handle exceptions where a
+ * delay is required to prevent a Thread from entering a tight loop which
+ * will consume CPU and may also trigger large amounts of logging. For
+ * example, this can happen with the Acceptor thread if the ulimit for open
+ * files is reached.
+ *
+ * @param currentErrorDelay The current delay beign applied on failure
+ * @return The delay to apply on the next failure
+ */
+protected int handleExceptionWithDelay(int currentErrorDelay) {
+// Don't delay on first exception
+if (currentErrorDelay > 0) {
+try {
+Thread.sleep(currentErrorDelay);
+} catch (InterruptedException e) {
+// Ignore
+}
+}
+
+// On subsequent exceptions, start the delay at 50ms, doubling the
delay
+// on every subsequent exception until the delay reaches 1.6 seconds.
+if (currentErrorDelay == 0) {
+return INITIAL_ERROR_DELAY;
+} else if (currentErrorDelay < MAX_ERROR_DELAY) {
+return currentErrorDelay * 2;
+} else {
+return MAX_ERROR_DELAY;
+}
+
+}
// SSL related properties
Modified: tomcat/trunk/java/org/apache/tomcat/util/net/AprEndpoint.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/util/net/AprEndpoint.java?rev=1073711&r1=1073710&r2=1073711&view=diff
==
--- tomcat/trunk/java/org/apache/tomcat/util/net/AprEndpoint.java (original)
+++ tomcat/trunk/java/org/apache/tomcat/util/net/AprEndpoint.java Wed Feb 23
11:58:47 2011
@@ -914,6 +914,8 @@ public class AprEndpoint extends Abstrac
@Override
public void run() {
+int errorDelay = 0;
+
// Loop until we receive a shutdown command
while (running) {
@@ -932,8 +934,21 @@ public class AprEndpoint extends Abstrac
try {
//if we have reached max connections, wait
awaitConnection();
-// Accept the next incoming connection from the server
socket
-long socket = Socket.accept(serverSock);
+
+long socket = 0;
+try {
+// Accept the next incoming connection from the server
+// socket
+socket = Socket.accept(serverSock);
+} catch (Exception e) {
+// Introduce delay if necessary
+errorDelay = handleExceptionWithDelay(errorDelay);
+// re-throw
+throw e;
+}
+// Successful accept, reset the error delay
+errorDelay = 0;
+
//increment socket count
countUpConnection();
/*
Modified: tomcat/trunk/java/org/apache/tomcat/util/net/JIoEndpoint.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/tomcat/util/net/JIoEndpoint.java?rev=1073711&r1=1073710&r2=1073711&view=diff
==
--- tomcat/trunk/java/org/apache/tomcat/util/net/JIoEndpoint.java (original)
+++ tomcat/trunk/java/org/apache/tom
Download stats
I took a quick look at yesterdays log files to see what the proportion of downloads was for the recent 5.5.x, 6.0.x and 7.0.x releases. After a little filtering to try and ensure I was comparing like with like, the results were: Tomcat 5.5.33 - 23% Tomcat 6.0.32 - 35% Tomcat 7.0.8 - 42% Looking across all versions: Tomcat 3.x - 1% Tomcat 4.x - 4% Tomcat 5.0.x - 5% Tomcat 5.5.x - 25% Tomcat 6.0.x - 33% Tomcat 7.0.x - 32% I also looked at new bug reports by version this month so far: Tomcat 5 - 2 Tomcat 6 - 12 Tomcat 7 - 19 My main purpose for this exercise was to try and gauge the uptake of Tomcat 7 and to see how usage of Tomcat compared to Tomcat 5 and 6. I don't think the data (or my analysis) is good enough to draw detailed conclusions but as a general picture of how Tomcat 7 adoption is going, I think things look pretty good. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 50819] Standard context is stopped BEFORE requesting session serialization
https://issues.apache.org/bugzilla/show_bug.cgi?id=50819 Mark Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Comment #1 from Mark Thomas 2011-02-23 10:45:09 EST --- Servlets should not be expiring sessions in the destroy() method. See section SRV.2.3.4 of the Servlet 2.5 specification for the reason why. -- 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: Download stats
Interesting to see TC 7.x at 32% 2011/2/23 Mark Thomas : > I took a quick look at yesterdays log files to see what the proportion > of downloads was for the recent 5.5.x, 6.0.x and 7.0.x releases. After a > little filtering to try and ensure I was comparing like with like, the > results were: > Tomcat 5.5.33 - 23% > Tomcat 6.0.32 - 35% > Tomcat 7.0.8 - 42% > > Looking across all versions: > Tomcat 3.x - 1% > Tomcat 4.x - 4% > Tomcat 5.0.x - 5% > Tomcat 5.5.x - 25% > Tomcat 6.0.x - 33% > Tomcat 7.0.x - 32% > > I also looked at new bug reports by version this month so far: > Tomcat 5 - 2 > Tomcat 6 - 12 > Tomcat 7 - 19 > > My main purpose for this exercise was to try and gauge the uptake of > Tomcat 7 and to see how usage of Tomcat compared to Tomcat 5 and 6. I > don't think the data (or my analysis) is good enough to draw detailed > conclusions but as a general picture of how Tomcat 7 adoption is going, > I think things look pretty good. > > Mark > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
svn commit: r1073891 - in /tomcat/trunk: bin/ conf/ java/org/apache/catalina/security/ res/confinstall/ webapps/docs/ webapps/docs/config/
Author: markt
Date: Wed Feb 23 19:23:59 2011
New Revision: 1073891
URL: http://svn.apache.org/viewvc?rev=1073891&view=rev
Log:
Add the SecurityListener (disabled by default) that prevents Tomcat from
starting if configured insecurely.
Added:
tomcat/trunk/java/org/apache/catalina/security/Constants.java (with props)
tomcat/trunk/java/org/apache/catalina/security/SecurityListener.java
(with props)
Modified:
tomcat/trunk/bin/catalina.sh
tomcat/trunk/conf/server.xml
tomcat/trunk/java/org/apache/catalina/security/LocalStrings.properties
tomcat/trunk/java/org/apache/catalina/security/SecurityUtil.java
tomcat/trunk/res/confinstall/server_1.xml
tomcat/trunk/webapps/docs/changelog.xml
tomcat/trunk/webapps/docs/config/listeners.xml
tomcat/trunk/webapps/docs/setup.xml
Modified: tomcat/trunk/bin/catalina.sh
URL:
http://svn.apache.org/viewvc/tomcat/trunk/bin/catalina.sh?rev=1073891&r1=1073890&r2=1073891&view=diff
==
--- tomcat/trunk/bin/catalina.sh (original)
+++ tomcat/trunk/bin/catalina.sh Wed Feb 23 19:23:59 2011
@@ -225,6 +225,10 @@ else
JAVA_OPTS="$JAVA_OPTS $LOGGING_MANAGER"
fi
+# Uncomment the following line to make the umask available when using the
+# org.apache.catalina.security.SecurityListener
+#JAVA_OPTS="$JAVA_OPTS
-Dorg.apache.catalina.security.SecurityListener.UMASK=`umask`"
+
# - Execute The Requested Command -
# Bugzilla 37848: only output this if we have a TTY
Modified: tomcat/trunk/conf/server.xml
URL:
http://svn.apache.org/viewvc/tomcat/trunk/conf/server.xml?rev=1073891&r1=1073890&r2=1073891&view=diff
==
--- tomcat/trunk/conf/server.xml (original)
+++ tomcat/trunk/conf/server.xml Wed Feb 23 19:23:59 2011
@@ -20,7 +20,9 @@
Documentation at /docs/config/server.html
-->
-
+
Added: tomcat/trunk/java/org/apache/catalina/security/Constants.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/security/Constants.java?rev=1073891&view=auto
==
--- tomcat/trunk/java/org/apache/catalina/security/Constants.java (added)
+++ tomcat/trunk/java/org/apache/catalina/security/Constants.java Wed Feb 23
19:23:59 2011
@@ -0,0 +1,25 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.catalina.security;
+
+public class Constants {
+
+public static final String PACKAGE = "org.apache.catalina.security";
+
+public static final String LINE_SEP = System.getProperty("line.separator");
+public static final String CRLF = "\r\n";
+}
Propchange: tomcat/trunk/java/org/apache/catalina/security/Constants.java
--
svn:eol-style = native
Modified: tomcat/trunk/java/org/apache/catalina/security/LocalStrings.properties
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/security/LocalStrings.properties?rev=1073891&r1=1073890&r2=1073891&view=diff
==
--- tomcat/trunk/java/org/apache/catalina/security/LocalStrings.properties
(original)
+++ tomcat/trunk/java/org/apache/catalina/security/LocalStrings.properties Wed
Feb 23 19:23:59 2011
@@ -14,4 +14,8 @@
# limitations under the License.
SecurityUtil.doAsPrivilege=An exception occurs when running the
PrivilegedExceptionAction block.
-
+SecurityListener.checkUmaskFail=Start attempted with umask setting of [{0}].
Running Tomcat without a umask at least as restrictive as [{1}] has been
blocked by the Lifecycle listener org.apache.catalina.security.SecurityListener
(usually configured in CATALINA_BASE/conf/server.xml)
+SecurityListener.checkUmaskNone=No umask setting was found in system property
[{0}]. However, it appears Tomcat is running on a platform that supports umask.
The system property is typically set in CATALINA_HOME/bin/catalina.sh. The
Lifecycle listener org.apache.catalina.security.SecurityListener (usually
configured in CATALINA_BA
svn commit: r1073893 - /tomcat/trunk/webapps/docs/security-howto.xml
Author: markt Date: Wed Feb 23 19:25:17 2011 New Revision: 1073893 URL: http://svn.apache.org/viewvc?rev=1073893&view=rev Log: Add security listener Modified: tomcat/trunk/webapps/docs/security-howto.xml Modified: tomcat/trunk/webapps/docs/security-howto.xml URL: http://svn.apache.org/viewvc/tomcat/trunk/webapps/docs/security-howto.xml?rev=1073893&r1=1073892&r2=1073893&view=diff == --- tomcat/trunk/webapps/docs/security-howto.xml (original) +++ tomcat/trunk/webapps/docs/security-howto.xml Wed Feb 23 19:25:17 2011 @@ -119,6 +119,9 @@ The APR Lifecycle Listener is not stable if compiled on Solaris using gcc. If using the APR/native connector on Solaris, compile it with the Sun Studio compiler. + + The Security Listener should be enabled and configured as appropriate. + - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
DO NOT REPLY [Bug 22405] warn if not deploy with umask "0077" or if deployed as "root" and provide tutorial URL "Secure deployment"
https://issues.apache.org/bugzilla/show_bug.cgi?id=22405 Mark Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #6 from Mark Thomas 2011-02-23 14:26:21 EST --- I have added the listener to 7.0.x and it will be included in 7.0.9 onwards. It has not been enabled by default as it may break current configurations such as IDE environments. It will be enabled by default in Tomcat 8. -- 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: Download stats
Mark, On 2/23/2011 10:27 AM, Mark Thomas wrote: > I took a quick look at yesterdays log files to see what the proportion > of downloads was for the recent 5.5.x, 6.0.x and 7.0.x releases. After a > little filtering to try and ensure I was comparing like with like, the > results were: > Tomcat 5.5.33 - 23% > Tomcat 6.0.32 - 35% > Tomcat 7.0.8 - 42% > > Looking across all versions: > Tomcat 3.x - 1% > Tomcat 4.x - 4% > Tomcat 5.0.x - 5% > Tomcat 5.5.x - 25% > Tomcat 6.0.x - 33% > Tomcat 7.0.x - 32% Maybe I don't understand, but how can the relative proportion of TC 6.0 vs. TC 7.0 change when more versions are considered? I would expect that TC 6.0 would always be less than TC 7.0 unless the time frames were different. > I think things look pretty good. People certainly aren't scared to download 7.0, which is great. Unfortunately, people are still downloading pre-6.0. :( -chris signature.asc Description: OpenPGP digital signature
Re: Download stats
On 23/02/2011 20:00, Christopher Schultz wrote: > Mark, > > On 2/23/2011 10:27 AM, Mark Thomas wrote: >> I took a quick look at yesterdays log files to see what the proportion >> of downloads was for the recent 5.5.x, 6.0.x and 7.0.x releases. After a >> little filtering to try and ensure I was comparing like with like, the >> results were: >> Tomcat 5.5.33 - 23% >> Tomcat 6.0.32 - 35% >> Tomcat 7.0.8 - 42% >> >> Looking across all versions: >> Tomcat 3.x - 1% >> Tomcat 4.x - 4% >> Tomcat 5.0.x - 5% >> Tomcat 5.5.x - 25% >> Tomcat 6.0.x - 33% >> Tomcat 7.0.x - 32% > > Maybe I don't understand, but how can the relative proportion of TC 6.0 > vs. TC 7.0 change when more versions are considered? The first only considered the latest versions of the 5.5.x, 6.0.x, & 7.0.x branches. The second set considered all versions of each branch. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
