Hi Ralph, I think that adding -DLog4jContextSelector=org.apache.logging.log4j.core.async.AsyncLoggerContextSelector to make all loggers asynchronous has solved this problem.
Thanks, Joan. -----Mensaje original----- De: Ralph Goers [mailto:ralph.go...@dslextreme.com] Enviado el: viernes, 28 de septiembre de 2018 18:41 Para: Log4J Users List Asunto: Re: Flush in RollingRandomAccessFile 1. The relevant appenders are listed below? If so, they are stopping correctly. Are they asynchronous? Can you provide the log4j2.xml? 2. I think the failure to shutdown the thread has been reported. It wouldn’t be causing your problem though. Ralph > On Sep 28, 2018, at 9:17 AM, Joan Balagueró - ventusproxy > <joan.balagu...@ventusproxy.com> wrote: > > Hi Ralph, > > Below the trace when tomcat is stopped: > > 28-Sep-2018 18:14:36.251 INFORMACIÓN [main] > org.apache.catalina.core.StandardServer.await Se ha recibido un comando de > apagado a través del puerto de apagado. Parando la instancia del Servidor. > 28-Sep-2018 18:14:36.252 INFORMACIÓN [main] > org.apache.coyote.AbstractProtocol.pause Pausing ProtocolHandler > ["http-nio-80"] > 28-Sep-2018 18:14:36.302 INFORMACIÓN [main] > org.apache.catalina.core.StandardService.stopInternal Parando servicio > [Catalina] > 2018-09-28 18:14:36,974 localhost-startStop-2 DEBUG Stopping > LoggerContext[name=3e73c8d6, > org.apache.logging.log4j.core.LoggerContext@64df2b5a]... > 2018-09-28 18:14:36,976 localhost-startStop-2 DEBUG Appender > CLUSTER_LOG stopped with status true > 2018-09-28 18:14:36,977 localhost-startStop-2 DEBUG Appender > SYSTEM_LOG stopped with status true > 2018-09-28 18:14:36,977 localhost-startStop-2 DEBUG Appender > MONITOR_LOG stopped with status true > 2018-09-28 18:14:36,977 localhost-startStop-2 DEBUG Appender ERROR_LOG > stopped with status true > 2018-09-28 18:14:36,977 localhost-startStop-2 DEBUG Appender > ACCESS_LOG stopped with status true > 2018-09-28 18:14:36,977 localhost-startStop-2 DEBUG Log4j2 > ConfigurationScheduler shutting down threads in > java.util.concurrent.ScheduledThreadPoolExecutor@7b51e3ab[Running, > pool size = 5, active threads = 0, queued tasks = 5, completed tasks = > 0] > 2018-09-28 18:14:36,977 localhost-startStop-2 DEBUG Stopped > XmlConfiguration[location=/home/ventusproxy/app/ROOT/WEB-INF/log4j.xml > ] OK > 2018-09-28 18:14:36,978 localhost-startStop-2 DEBUG Stopped > LoggerContext[name=3e73c8d6, > org.apache.logging.log4j.core.LoggerContext@64df2b5a] with status true > 2018-09-28 18:14:36,978 localhost-startStop-2 DEBUG Log4jServletFilter > destroyed. > 2018-09-28 18:14:36,979 localhost-startStop-2 DEBUG > Log4jServletContextListener ensuring that Log4j shuts down properly. > 28-Sep-2018 18:14:36.984 ADVERTENCIA [localhost-startStop-2] > org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The > web application [ROOT] appears to have started a thread named > [Log4j2-TF-7-Scheduled-6] but has fail ed to stop it. This is very likely to > create a memory leak. Stack trace of thread: > sun.misc.Unsafe.park(Native Method) > java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:215) > java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject. > awaitNanos(AbstractQueuedSynchronizer.java:2078) > java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take > (ScheduledThreadPoolExecutor.java:1093) > java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take > (ScheduledThreadPoolExecutor.java:809) > java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.jav > a:1074) > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.j > ava:1134) > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor. > java:624) > java.lang.Thread.run(Thread.java:748) > 28-Sep-2018 18:14:37.025 INFORMACIÓN [main] > org.apache.coyote.AbstractProtocol.stop Stopping ProtocolHandler > ["http-nio-80"] > 28-Sep-2018 18:14:37.055 INFORMACIÓN [main] > org.apache.coyote.AbstractProtocol.destroy Destroying ProtocolHandler > ["http-nio-80"] > > Thanks, > > Joan. > > -----Mensaje original----- > De: Ralph Goers [mailto:ralph.go...@dslextreme.com] > Enviado el: viernes, 28 de septiembre de 2018 18:00 > Para: Log4J Users List > Asunto: Re: Flush in RollingRandomAccessFile > > That all sounds correct to me. I would suggest you add status=“DEBUG” to the > configuration element in your log4j2.xml and see what happens during shutdown. > > Ralph > >> On Sep 28, 2018, at 8:57 AM, Joan Balagueró - ventusproxy >> <joan.balagu...@ventusproxy.com> wrote: >> >> Hello, >> >> The jars we have in our app are: log4j-1.2-api-2.11.1.jar, >> log4j-api-2.11.1.jar, log4j-core-2.11.1.jar and log4j-web-2.11.1.jar. >> >> Are the right jars, or may I add something else? >> >> Thanks, >> >> Joan. >> >> -----Mensaje original----- >> De: Joan Balagueró - ventusproxy >> [mailto:joan.balagu...@ventusproxy.com] >> Enviado el: jueves, 27 de septiembre de 2018 18:20 >> Para: 'Log4J Users List' >> Asunto: RE: Flush in RollingRandomAccessFile >> >> It seems my web.xml is ok. It's a servlet 3.1 with tomcat 8.5.32. I only >> have this context parameter, necessary for a correct log4j startup: >> >> <web-app xmlns="http://xmlns.jcp.org/xml/ns/javaee"; >> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; >> xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee >> http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd"; >> version="3.1"> >> >> <display-name>ventusproxy</display-name> >> <description>ventusproxy</description> >> >> <context-param> >> <param-name>isLog4jContextSelectorNamed</param-name> >> <param-value>true</param-value> </context-param> >> >> <context-param> >> <param-name>log4jContextName</param-name> >> <param-value>ventusproxy</param-value> >> </context-param> >> >> ( ... ) >> >> Joan. >> >> >> -----Mensaje original----- >> De: Ralph Goers [mailto:ralph.go...@dslextreme.com] >> Enviado el: jueves, 27 de septiembre de 2018 18:05 >> Para: Log4J Users List >> Asunto: Re: Flush in RollingRandomAccessFile >> >> That depends on what servlet version you are using. Take a look at >> http://logging.apache.org/log4j/2.x/manual/webapp.html >> <http://logging.apache.org/log4j/2.x/manual/webapp.html>. >> >> Ralph >> >>> On Sep 27, 2018, at 9:02 AM, Joan Balagueró - ventusproxy >>> <joan.balagu...@ventusproxy.com> wrote: >>> >>> Hi Ralph, >>> >>> After adding the log4j-web-2.11.1.jar to our app, it doesn't work yet. >>> >>> Do I need to add something to the web.xml file, or some environment >>> variable? >>> >>> Thanks, >>> >>> Joan. >>> >>> -----Mensaje original----- >>> De: Ralph Goers [mailto:ralph.go...@dslextreme.com] >>> Enviado el: jueves, 27 de septiembre de 2018 17:33 >>> Para: Log4J Users List >>> Asunto: Re: Flush in RollingRandomAccessFile >>> >>> Are you using the log4j-web jar? It is supposed to handle this. >>> >>> Ralph >>> >>>> On Sep 27, 2018, at 8:14 AM, Joan Balagueró - ventusproxy >>>> <joan.balagu...@ventusproxy.com> wrote: >>>> >>>> Hello, >>>> >>>> >>>> >>>> After sending thousands of requests to our app, we stop the sender >>>> and the log file appears like below: >>>> >>>> >>>> >>>> 1,54.38.179.175,2018-09-27 >>>> 16:55:51.618,A,13,A,39,A,72,A,120,N,,54.38.179.182:8080,g,8457,403, >>>> 6 >>>> 8 >>>> 3 >>>> ,58,ok >>>> ,2018-09-27 16:55:51.677 >>>> >>>> 1,54.38.179.17 >>>> >>>> >>>> >>>> Now we stop tomcat (when our app is running). And it seems the >>>> queue of pending events is not flushed, so the log remains like >>>> above. Our log configuration is: >>>> >>>> >>>> >>>> <RollingRandomAccessFile name="ACCESS_LOG" >>>> fileName="${sys:log.dir}vproxy_access" >>>> filePattern="${sys:log.dir}vproxy_access.%d{yyyy-MM-dd}" append="true" >>>> immediateFlush="false"> >>>> >>>> <PatternLayout> >>>> >>>> Pattern>%m%d{yyyy-MM-dd HH:mm:ss.SSS}%n</Pattern> >>>> >>>> </PatternLayout> >>>> >>>> <Policies> >>>> >>>> <CronTriggeringPolicy schedule="0 0 0 * * ?" evaluateOnStartup="true" >>>> /> >>>> >>>> </Policies> >>>> >>>> </RollingRandomAccessFile> >>>> >>>> >>>> >>>> <Logger name="LOGGER_ACCESS" level="info" includeLocation="false" >>>> additivity="false"> >>>> >>>> <AppenderRef ref="ACCESS_LOG"/> >>>> >>>> </Logger> >>>> >>>> >>>> >>>> >>>> >>>> Can we tell log4j2 to flush these pending lines when we shutdown our app? >>>> >>>> >>>> >>>> Thanks, >>>> >>>> Joan. >>>> >>>> >>>> >>> >>> >>> >>> -------------------------------------------------------------------- >>> - 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 >>> >>> >> >> >> >> --------------------------------------------------------------------- >> 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 >> >> > > > > --------------------------------------------------------------------- > 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 > > --------------------------------------------------------------------- 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
