I didn't think it was possible to use Log4j2 for tomcat container logging. I 
thought they implemented a custom extension of Java util logging to prevent 
application logging issues to interfere with the container. But I could be 
wrong. 

Sent from my iPhone

> On Apr 19, 2017, at 8:38, Ankit Agarwal <ankit_agar...@yahoo.com.INVALID> 
> wrote:
> 
> 
> 
> 
>    On Monday, April 10, 2017 5:20 PM, Remko Popma <remko.po...@gmail.com> 
> wrote:
> 
> 
>> If you enable internal Log4j2 logging with <Configuration status ="trace"> 
>> at the top of your configuration, then you should see internal Log4j2 
>> logging on the console. 
>> It should show details of what happens during a rollover. Can you post that 
>> output?
> My original hypothesis was wrong. The problem does not arise during a 
> rollover.
> 
> Here is what I have found so far. I see this behavior on my development 
> machine.
> I did not use the Tomcat 8 installation for the entire weekend, i.e., 2 days 
> or so. Did not use means that I did not visit my web application via a 
> browser, did not deploy a new WAR, did not restart Tomcat, etc. I just left 
> it running as is.
> Sometime during the weekend, Tomcat zipped up my log files - catalina.out, 
> localhost.log, manager.log, and even my web applications own log file which 
> is written to a sub-directory of "/var/log/tomcat8".
> From the zip file timestamps it looks like this was approximately 24 hours 
> after I last used Tomcat.
> Once the zip files were created, replacement log files were not created.
> Now, when I visit the web application via a browser, no logs are written (as 
> there is no log file). No error is added to "catalina.out" either. It is 0 
> bytes since the last catalina.out file was zipped up.
> If I try to redeploy my WAR, it fails and there is no error in the Tomcat 
> Admin Manager UI - this is because the localhost.log file has been zipped and 
> a new one has not been created. If I restart the Tomcat, this problem will go 
> away.
> 
> Interestingly, the catalina.log file does not have this problem, and I 
> believe it is because I have the TRACE level logging enabled as you had 
> suggested. So Tomcat is writing logs to catalina.log every second (even when 
> it is idle).
> Given all this, the only logs I have are from the catalina.log file and they 
> are of this type:
> 18 Apr 2017 16:35:23,472 "2017-04-18T16:35:23,472" "CMS" "Tomcat" "" "" "" "" 
> "" "" "52.25.59.238" "59" "http-nio-443-ClientPoller-1" "" "" "" "[]" 
> "org.apache.tomcat.util.net.NioEndpoint$Poller.timeout(NioEndpoint.java:1318)"
>  "TRACE" "timeout completed: keys processed=0; now=1492558523472; 
> nextExpiration=1492558523471; keyCount=0; hasEvents=false; eval=false"
> 18 Apr 2017 16:35:23,904 "2017-04-18T16:35:23,904" "CMS" "Tomcat" "" "" "" "" 
> "" "" "52.25.59.238" "54" 
> "ContainerBackgroundProcessor[StandardEngine[Catalina]]" "" "" "" "[]" 
> "org.apache.catalina.startup.HostConfig.checkResources(HostConfig.java:1249)" 
> "DEBUG" "Checking context[] redeploy resource 
> /var/lib/tomcat8/webapps/ROOT.war"
> 
> It seems that Tomcat (or Log4J/Log4J2) automatically zips up log files after 
> inactivity of 24 hours or so and fails to create replacement log files.
> 
> Any thoughts on this? Has you seen this kind of behavior before?
> 
> Thanks,Ankit
> 
> 
> Sent from my iPhone
> 
>> On Apr 11, 2017, at 4:07, Ankit Agarwal <ankit_agar...@yahoo.com.INVALID> 
>> wrote:
>> 
>> Hi,
>> 
>> I’m using Log4J2 (2.8) via the 1.2 API Bridge for Tomcat 8 internal logging.
>> 
>> I followed the instructions here: 
>> https://tomcat.apache.org/tomcat-8.0-doc/logging.html#Using_Log4j 
>> <https://tomcat.apache.org/tomcat-8.0-doc/logging.html#Using_Log4j>
>> - With the exception that I also copied the Bridge JAR into the Tomcat8 lib 
>> directory
>> 
>> I have configured Log4J2 with this XML file
>> 
>> <?xml version="1.0" encoding="utf-8"?>
>> <Configuration status="info">
>>     <Properties>
>>           <Property name="logDirectory">${sys:catalina.base}/logs</Property>
>>           <Property name="systemName">CMS</Property>
>>           <Property name="componentName">Tomcat</Property>
>>           <Property 
>> name="serverIpAddress">${env:PUBLIC_IP_ADDRESS}</Property>
>>           <!-- <Property name="layout">%d [%t] %-5p %c- %m%n</Property> -->
>>           <Property name="layout">%d{DATE} "%d{ISO8601}" "${systemName}" 
>> "${componentName}" "%X{clientIpAddress}" "%X{clientTcpPort}" "%X{username}" 
>> "%X{sessionId}" "%X{sessionAuthenticationId}" 
>> "%X{sessionAuthenticationToken}" "${serverIpAddress}" "%T" "%t" 
>> "%X{apiName}" "%X{apiSystemActionType}" "%X{apiSystemItemType}" "%x" "%l" 
>> "%p" "%m"%n%n</Property>
>>     </Properties>
>>     <Appenders>
>>           <Console name="CONSOLE" target="SYSTEM_OUT">
>>               <PatternLayout pattern="${layout}"/>
>>           </Console>
>>           <RollingFile name="CATALINA" 
>> fileName="${logDirectory}/catalina.log" 
>> filePattern="${logDirectory}/catalina-%i.log.gz">
>>               <PatternLayout pattern="${layout}"/>
>>               <Policies>
>>                     <SizeBasedTriggeringPolicy size=“100 MB" />
>>               </Policies>
>>               <DefaultRolloverStrategy max="20" />
>>           </RollingFile>
>>           <RollingFile name="LOCALHOST" 
>> fileName="${logDirectory}/localhost.log" 
>> filePattern="${logDirectory}/localhost-%i.log.gz">
>>               <PatternLayout pattern="${layout}"/>
>>               <Policies>
>>                     <SizeBasedTriggeringPolicy size="100 MB"/>
>>               </Policies>
>>               <DefaultRolloverStrategy max="20" />
>>           </RollingFile>
>>           <RollingFile name="MANAGER" fileName="${logDirectory}/manager.log" 
>> filePattern="${logDirectory}/manager-%i.log.gz">
>>               <PatternLayout pattern="${layout}"/>
>>               <Policies>
>>                     <SizeBasedTriggeringPolicy size="100 MB"/>
>>               </Policies>
>>               <DefaultRolloverStrategy max="20" />
>>           </RollingFile>
>>           <RollingFile name="HOST-MANAGER" 
>> fileName="${logDirectory}/host-manager.log" 
>> filePattern="${logDirectory}/host-manager-%i.log.gz">
>>               <PatternLayout pattern="${layout}"/>
>>               <Policies>
>>                     <SizeBasedTriggeringPolicy size="100 MB"/>
>>               </Policies>
>>               <DefaultRolloverStrategy max="20" />
>>           </RollingFile>
>>     </Appenders>
>>     <Loggers>
>>           <Root level="info">
>>               <AppenderRef ref="CATALINA"/>
>>           </Root>
>>           <Logger 
>> name="org.apache.catalina.core.ContainerBase.[Catalina].[localhost]" 
>> level="info" additivity="false">
>>               <AppenderRef ref="LOCALHOST"/>
>>           </Logger>
>>           <Logger 
>> name="org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/manager]"
>>  level="info" additivity="false">
>>               <AppenderRef ref="MANAGER"/>
>>           </Logger>
>>           <Logger 
>> name="org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/host-manager]"
>>  level="info" additivity="false">
>>               <AppenderRef ref="HOST-MANAGER"/>
>>           </Logger>
>>     </Loggers>
>> </Configuration>
>> 
>> 
>> All 4 RollingFile Appenders are configured identically (except for the log 
>> filename).
>> 
>> The problem I’m running into is that when the SizeBasedTriggeringPolicy is 
>> executed, the current log file is zipped. However, a new log file is not 
>> created.
>> 
>> As a result, the Tomcat8 stops logging.
>> 
>> If I restart Tomcat8, then a new file is created and the Tomcat8 functions 
>> normally, but only until this new log file reaches its limit and is zipped 
>> up. Then once again, the problem repeats itself.
>> 
>> Does the 1.2 API Bridge not support the SizeBasedTriggeringPolicy?
>> 
>> Do I have any options other than restarting the Tomcat8? Will the 
>> TimeBasedTriggeringPolicy work and is that my only option?
>> 
>> Since the Log4J2 being used in Tomcat8 has no problem creating the required 
>> files on restart, I don’t think its a permissions issue.
>> 
>> I’d appreciate any thoughts and pointers.
>> 
>> Thanks,
>> Ankit
>> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
> For additional commands, e-mail: log4j-user-h...@logging.apache.org
> 
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-user-h...@logging.apache.org

Reply via email to