Hi Violeta,
Am 16.06.2017 um 21:17 schrieb violet...@apache.org:
Author: violetagg
Date: Fri Jun 16 19:17:39 2017
New Revision: 1798977
URL: http://svn.apache.org/viewvc?rev=1798977&view=rev
Log:
Fix https://bz.apache.org/bugzilla/show_bug.cgi?id=61105
Add a new JULI FileHandler configuration for specifying the maximum number of
days to keep the log files. By default the log files will be kept 90 days as
configured in logging.properties.
Added:
tomcat/trunk/test/org/apache/juli/TestFileHandler.java (with props)
Modified:
tomcat/trunk/conf/logging.properties
tomcat/trunk/java/org/apache/juli/AsyncFileHandler.java
tomcat/trunk/java/org/apache/juli/FileHandler.java
tomcat/trunk/webapps/docs/changelog.xml
tomcat/trunk/webapps/docs/logging.xml
...
Modified: tomcat/trunk/java/org/apache/juli/FileHandler.java
URL:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/juli/FileHandler.java?rev=1798977&r1=1798976&r2=1798977&view=diff
==============================================================================
--- tomcat/trunk/java/org/apache/juli/FileHandler.java (original)
+++ tomcat/trunk/java/org/apache/juli/FileHandler.java Fri Jun 16 19:17:39 2017
...
@@ -74,24 +84,37 @@ import java.util.logging.LogRecord;
* <li><code>formatter</code> - The <code>java.util.logging.Formatter</code>
* implementation class name for this Handler. Default value:
* <code>java.util.logging.SimpleFormatter</code></li>
+ * <li><code>maxDays</code> - The maximum number of days to keep the log
+ * files. If the specified value is <code><=0</code> then the log files
+ * will be kept on the file system forever, otherwise they will be kept the
+ * specified maximum days. Default value: <code>-1</code>.</li>
* </ul>
*/
public class FileHandler extends Handler {
+ public static final int DEFAULT_MAX_DAYS = -1;
+
+ private static final ExecutorService DELETE_FILES_SERVICE =
Executors.newSingleThreadExecutor();
When testing the M22 release I noticed that a tomcat process was
leftover that didn't want to shut down. I checked and I could easily
reproduce by starting with startup.sh and then stopping with shutdown.sh
(but not using kill). IMHO it didn't shut down, because according to a
thread dump it had a single non-daemon thread still running (named
"pool-1-thread-1"). Since we typically give more specific names to all
threads we create I instrumented the Thread class to find out the
creator of that thread and noticed, that it was created here:
at java.lang.Thread.<init>(Thread.java:677)
at
java.util.concurrent.Executors$DefaultThreadFactory.newThread(Executors.java:613)
at
java.util.concurrent.ThreadPoolExecutor$Worker.<init>(ThreadPoolExecutor.java:612)
at
java.util.concurrent.ThreadPoolExecutor.addWorker(ThreadPoolExecutor.java:925)
at
java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1357)
at
java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:112)
at
java.util.concurrent.Executors$DelegatedExecutorService.submit(Executors.java:678)
at org.apache.juli.FileHandler.clean(FileHandler.java:463)
at org.apache.juli.FileHandler.<init>(FileHandler.java:117)
at
org.apache.juli.AsyncFileHandler.<init>(AsyncFileHandler.java:82)
at
org.apache.juli.AsyncFileHandler.<init>(AsyncFileHandler.java:74)
So it is the thread belonging to the above "ExecutorService
DELETE_FILES_SERVICE". I could not see, how that thread would ever get
stopped, so two remarks:
- in order to make sure TC can shut down without problem we either need
to stop that thread by ourselves during TC shutdown or mark it as a
daemon thread. I guess the latter is preferred.
- we should give the created thread a specific name according to its
typical task so that it can be identified in any thread dump. That
should be doable by the same ThreadFactory.
So we need to pass a ThreadFactory to the newSingleThreadExecutor() call
(this possibility already exists in the Executors class). To keep juli
independent from the other TC classes, we probably need to code the
factory inside juli, but we can borrow code from the small class
org.apache.tomcat.util.threads.TaskThreadFactory or use code from there
to extend the result of Executors.defaultThreadFactory() or
Executors.privilegedThreadFactory().
Regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
