Since Tomcat 8 our JULI config uses AsyncFileHandler by default.
The default config of AsyncFileHandler allows log records to be dropped once the log queue gets full. I'd say this is not a sane default and suggest that we switch the default to the "block logging thread until there's again space in the queue" option. Of course that will mean Tomcat threads start to hang in logging once the queue gets full. But simply throwing away log messages should be an explicit choice of an admin and not our release default IMHO.
I suggest to switch defaults to OVERFLOW_DROP_FLUSH (and also to rename that constant to OVERFLOW_DROP_WAIT).
Then there's currently a config setting org.apache.juli.AsyncLoggerPollInterval which controls how long the thread that polls the queue blocks waiting for the next log record to show up in the queue. If the timeout fires, it immediately starts to poll again. I don't really understand, why this should be configurable. IMHO the only reason for this poll timeout would be to allow the polling thread to stop. For instance if JULI needs to get unloaded, e.g. when being embedded or in a per webapp use, then an endless blocking poller thread might not be good. But in fact although the thread has a "run" flag which could control stopping it, the flag is never set to false! The thread is marked as daemon though.
I suggest to remove the system property org.apache.juli.AsyncLoggerPollInterval.
I suggest to also orderly shut down the thread during ClassLoaderogManager shutdown. Since the thread is static, that would mean making the "run" flag volatile, letting AsyncFileHandler count it's non-closed instances and set "run" to false in the close() method when the last instance is closed. Alternatively one could make the queue and the polling thread non-global but per instance and shut the thread down in close(). I would find the latter easier and also more plausible. Don't know what good reason there is to share the queue and the thread.
Comments? Thanks and regards, Rainer --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
