April 2009 - logback-dev - mailman3.qos.ch

[JIRA] Created: (LBCORE-58) AppenderBase doAppend is synchronized causing significant performance problems when calling appenders.
by Ralph Goers (JIRA) 26 Jun '09

26 Jun '09

AppenderBase doAppend is synchronized causing significant performance problems when calling appenders. ------------------------------------------------------------------------------------------------------ Key: LBCORE-58 URL: http://jira.qos.ch/browse/LBCORE-58 Project: logback-core Issue Type: Bug Components: Appender Affects Versions: 0.9.10 Environment: All Reporter: Ralph Goers Assignee: Logback dev list Slow appenders cause Logback to be a significant bottleneck in the system. AppenderBase doAppend is synchronized to allow Appenders to be threadsafe. This is an extremely poor way to accomplish that. Many Appenders are slow since they are dealing with I/O of some kind but may be thread safe. Where they are not they should deal with the issue at the smallest granularity possible. AppenderBase must be changed to not be synchronized and any Appenders that are not thread safe should be modified appropriately. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

2 6

[JIRA] Created: (LBCORE-62) Dinimish contention among concurrent threads when using logback
by Ceki Gulcu (JIRA) 26 Jun '09

26 Jun '09

Dinimish contention among concurrent threads when using logback --------------------------------------------------------------- Key: LBCORE-62 URL: http://jira.qos.ch/browse/LBCORE-62 Project: logback-core Issue Type: Improvement Components: Appender Affects Versions: 0.9.9 Reporter: Ceki Gulcu Assignee: Ceki Gulcu Fix For: 0.9.10 We should strive to diminish interference among concurrent threads when using logback. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

1 1

[JIRA] Created: (LBCLASSIC-110) TargetLengthBasedClassNameAbbreviator does not work for strings with more than 12 dots (inclusive).
by Lukas Zapletal (JIRA) 22 Jun '09

22 Jun '09

TargetLengthBasedClassNameAbbreviator does not work for strings with more than 12 dots (inclusive). --------------------------------------------------------------------------------------------------- Key: LBCLASSIC-110 URL: http://jira.qos.ch/browse/LBCLASSIC-110 Project: logback-classic Issue Type: Bug Components: appender Affects Versions: 0.9.9, 0.9.10, 0.9.11, 0.9.12, 0.9.13, 0.9.14, 0.9.15 Reporter: Lukas Zapletal Assignee: Logback dev list Please add this to TargetLengthBasedClassNameAbbreviatorTest: System.out.println("13"); { // 13 dots test TargetLengthBasedClassNameAbbreviator abbreviator = new TargetLengthBasedClassNameAbbreviator(20); String name = "com.pike.test.puma.wm.isd2dita.core.g.project.server.pkg.isobjecttype.isobject.ISObjectContentGenerator"; assertEquals("c.p.t.p.w.i.c.g.o.s.r.i.ISObjectContentGenerator", abbreviator.abbreviate(name)); } System.out.println("12"); { // 12 dots test TargetLengthBasedClassNameAbbreviator abbreviator = new TargetLengthBasedClassNameAbbreviator(20); String name = "com.pike.puma.wm.isd2dita.core.g.project.server.pkg.isobjecttype.isobject.ISObjectContentGenerator"; assertEquals("c.p.p.w.i.c.g.o.s.r.i.ISObjectContentGenerator", abbreviator.abbreviate(name)); } Logs are disappearing when this bug occurs. It throws ArrayIndexOfBounds when testing but in production logs are just skipped (thus this bug is not FATAL-CRITICAL). Workaround: higher the 12 dot limit. Better workaround: handle with strings correctly not to ses AIOB exception ever. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

2 3

[JIRA] Created: (LBCORE-96) Deadlock when running on multiple core processors
by Lars Feistner (JIRA) 28 May '09

28 May '09

Deadlock when running on multiple core processors ------------------------------------------------- Key: LBCORE-96 URL: http://jira.qos.ch/browse/LBCORE-96 Project: logback-core Issue Type: Bug Components: Appender Affects Versions: 0.9.15 Environment: Windows Vista quad core Apache Tomcat 6.0.18 JDK 1.6 Reporter: Lars Feistner Assignee: Logback dev list As Robert Dale mentioned on 23/Mar/09 04:05 PM I'm getting that deadlock in logback core (0.9.14 and 0.9.15). No console plugin or socket appenders, just plain RollingFileAppender. I am getting the deadlock using ConsoleAppender. see attached thread dump: 2009-04-06 11:49:45 Full thread dump Java HotSpot(TM) Client VM (11.0-b12 mixed mode, sharing): "http-8084-5" daemon prio=6 tid=0x04700c00 nid=0xc54 in Object.wait() [0x05d1f000..0x05d1fc68] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on <0x24338c70> (a org.apache.tomcat.util.net.JIoEndpoint$Worker) at java.lang.Object.wait(Object.java:485) at org.apache.tomcat.util.net.JIoEndpoint$Worker.await(JIoEndpoint.java:416) - locked <0x24338c70> (a org.apache.tomcat.util.net.JIoEndpoint$Worker) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:442) at java.lang.Thread.run(Thread.java:619) "http-8084-4" daemon prio=6 tid=0x04700000 nid=0xe24 in Object.wait() [0x05c7f000..0x05c7fbe8] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on <0x24254da8> (a org.apache.tomcat.util.net.JIoEndpoint$Worker) at java.lang.Object.wait(Object.java:485) at org.apache.tomcat.util.net.JIoEndpoint$Worker.await(JIoEndpoint.java:416) - locked <0x24254da8> (a org.apache.tomcat.util.net.JIoEndpoint$Worker) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:442) at java.lang.Thread.run(Thread.java:619) "http-8084-3" daemon prio=6 tid=0x04700400 nid=0x134c waiting for monitor entry [0x05c2f000..0x05c2fa68] java.lang.Thread.State: BLOCKED (on object monitor) at ch.qos.logback.core.AppenderBase.doAppend(AppenderBase.java:66) - waiting to lock <0x23b16ac8> (a ch.qos.logback.core.ConsoleAppender) at ch.qos.logback.core.spi.AppenderAttachableImpl.appendLoopOnAppenders(AppenderAttachableImpl.java:60) at ch.qos.logback.classic.Logger.appendLoopOnAppenders(Logger.java:270) at ch.qos.logback.classic.Logger.callAppenders(Logger.java:257) at ch.qos.logback.classic.Logger.buildLoggingEventAndAppend(Logger.java:439) at ch.qos.logback.classic.Logger.filterAndLog_1(Logger.java:411) at ch.qos.logback.classic.Logger.debug(Logger.java:504) at de.ims.server.jguard.ImsRemoteServiceServlet.processCall(ImsRemoteServiceServlet.java:88) at com.google.gwt.user.server.rpc.RemoteServiceServlet.doPost(RemoteServiceServlet.java:86) at javax.servlet.http.HttpServlet.service(HttpServlet.java:637) at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.netbeans.modules.web.monitor.server.MonitorFilter.doFilter(MonitorFilter.java:390) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:286) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:845) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447) at java.lang.Thread.run(Thread.java:619) "Thread-10" daemon prio=6 tid=0x046ff800 nid=0x122c runnable [0x05bdf000..0x05bdfb68] java.lang.Thread.State: RUNNABLE at sun.net.dns.ResolverConfigurationImpl.notifyAddrChange0(Native Method) at sun.net.dns.ResolverConfigurationImpl$AddressChangeListener.run(ResolverConfigurationImpl.java:125) "http-8084-2" daemon prio=6 tid=0x046ff400 nid=0x17f4 waiting for monitor entry [0x05b8f000..0x05b8fa68] java.lang.Thread.State: BLOCKED (on object monitor) at ch.qos.logback.core.AppenderBase.doAppend(AppenderBase.java:66) - waiting to lock <0x23b16ac8> (a ch.qos.logback.core.ConsoleAppender) at ch.qos.logback.core.spi.AppenderAttachableImpl.appendLoopOnAppenders(AppenderAttachableImpl.java:60) at ch.qos.logback.classic.Logger.appendLoopOnAppenders(Logger.java:270) at ch.qos.logback.classic.Logger.callAppenders(Logger.java:257) at ch.qos.logback.classic.Logger.buildLoggingEventAndAppend(Logger.java:439) at ch.qos.logback.classic.Logger.filterAndLog_1(Logger.java:411) at ch.qos.logback.classic.Logger.debug(Logger.java:504) at de.ims.server.jguard.ImsRemoteServiceServlet.processCall(ImsRemoteServiceServlet.java:88) at com.google.gwt.user.server.rpc.RemoteServiceServlet.doPost(RemoteServiceServlet.java:86) at javax.servlet.http.HttpServlet.service(HttpServlet.java:637) at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.netbeans.modules.web.monitor.server.MonitorFilter.doFilter(MonitorFilter.java:390) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:286) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:845) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447) at java.lang.Thread.run(Thread.java:619) "TP-Monitor" daemon prio=6 tid=0x04a17400 nid=0x830 in Object.wait() [0x05b3f000..0x05b3fce8] java.lang.Thread.State: TIMED_WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on <0x23e0a900> (a org.apache.tomcat.util.threads.ThreadPool$MonitorRunnable) at org.apache.tomcat.util.threads.ThreadPool$MonitorRunnable.run(ThreadPool.java:565) - locked <0x23e0a900> (a org.apache.tomcat.util.threads.ThreadPool$MonitorRunnable) at java.lang.Thread.run(Thread.java:619) "TP-Processor4" daemon prio=6 tid=0x0497a000 nid=0x11dc runnable [0x05a8f000..0x05a8fd68] java.lang.Thread.State: RUNNABLE at java.net.PlainSocketImpl.socketAccept(Native Method) at java.net.PlainSocketImpl.accept(PlainSocketImpl.java:384) - locked <0x23e0a9b0> (a java.net.SocksSocketImpl) at java.net.ServerSocket.implAccept(ServerSocket.java:453) at java.net.ServerSocket.accept(ServerSocket.java:421) at org.apache.jk.common.ChannelSocket.accept(ChannelSocket.java:306) at org.apache.jk.common.ChannelSocket.acceptConnections(ChannelSocket.java:660) at org.apache.jk.common.ChannelSocket$SocketAcceptor.runIt(ChannelSocket.java:870) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:690) at java.lang.Thread.run(Thread.java:619) "TP-Processor3" daemon prio=6 tid=0x04979c00 nid=0xfe8 in Object.wait() [0x05a3f000..0x05a3f9e8] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on <0x23e0abc8> (a org.apache.tomcat.util.threads.ThreadPool$ControlRunnable) at java.lang.Object.wait(Object.java:485) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:662) - locked <0x23e0abc8> (a org.apache.tomcat.util.threads.ThreadPool$ControlRunnable) at java.lang.Thread.run(Thread.java:619) "TP-Processor2" daemon prio=6 tid=0x04982800 nid=0x10bc in Object.wait() [0x059ef000..0x059efa68] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on <0x23e0ac68> (a org.apache.tomcat.util.threads.ThreadPool$ControlRunnable) at java.lang.Object.wait(Object.java:485) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:662) - locked <0x23e0ac68> (a org.apache.tomcat.util.threads.ThreadPool$ControlRunnable) at java.lang.Thread.run(Thread.java:619) "TP-Processor1" daemon prio=6 tid=0x04982000 nid=0x131c in Object.wait() [0x0599f000..0x0599fae8] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on <0x23e0ad08> (a org.apache.tomcat.util.threads.ThreadPool$ControlRunnable) at java.lang.Object.wait(Object.java:485) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:662) - locked <0x23e0ad08> (a org.apache.tomcat.util.threads.ThreadPool$ControlRunnable) at java.lang.Thread.run(Thread.java:619) "http-8084-1" daemon prio=6 tid=0x04917000 nid=0x15f4 runnable [0x0594f000..0x0594fb68] java.lang.Thread.State: RUNNABLE at java.io.FileOutputStream.writeBytes(Native Method) at java.io.FileOutputStream.write(FileOutputStream.java:260) at java.io.BufferedOutputStream.write(BufferedOutputStream.java:105) - locked <0x2395d280> (a java.io.BufferedOutputStream) at java.io.PrintStream.write(PrintStream.java:430) - locked <0x23951d08> (a java.io.PrintStream) at org.apache.tomcat.util.log.SystemLogHandler.write(SystemLogHandler.java:166) at sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:202) at sun.nio.cs.StreamEncoder.implFlushBuffer(StreamEncoder.java:272) at sun.nio.cs.StreamEncoder.implFlush(StreamEncoder.java:276) at sun.nio.cs.StreamEncoder.flush(StreamEncoder.java:122) - locked <0x23b1c1f0> (a java.io.OutputStreamWriter) at java.io.OutputStreamWriter.flush(OutputStreamWriter.java:212) at ch.qos.logback.core.WriterAppender.writerWrite(WriterAppender.java:245) at ch.qos.logback.core.WriterAppender.subAppend(WriterAppender.java:261) at ch.qos.logback.core.WriterAppender.append(WriterAppender.java:114) at ch.qos.logback.core.AppenderBase.doAppend(AppenderBase.java:87) - locked <0x23b16ac8> (a ch.qos.logback.core.ConsoleAppender) at ch.qos.logback.core.spi.AppenderAttachableImpl.appendLoopOnAppenders(AppenderAttachableImpl.java:60) at ch.qos.logback.classic.Logger.appendLoopOnAppenders(Logger.java:270) at ch.qos.logback.classic.Logger.callAppenders(Logger.java:257) at ch.qos.logback.classic.Logger.buildLoggingEventAndAppend(Logger.java:439) at ch.qos.logback.classic.Logger.filterAndLog_1(Logger.java:411) at ch.qos.logback.classic.Logger.debug(Logger.java:504) at de.ims.server.jguard.ImsRemoteServiceServlet.processCall(ImsRemoteServiceServlet.java:92) at com.google.gwt.user.server.rpc.RemoteServiceServlet.doPost(RemoteServiceServlet.java:86) at javax.servlet.http.HttpServlet.service(HttpServlet.java:637) at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.netbeans.modules.web.monitor.server.MonitorFilter.doFilter(MonitorFilter.java:390) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:286) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:845) at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583) at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447) at java.lang.Thread.run(Thread.java:619) "http-8084-Acceptor-0" daemon prio=6 tid=0x049c2400 nid=0x129c runnable [0x058bf000..0x058bfbe8] java.lang.Thread.State: RUNNABLE at java.net.PlainSocketImpl.socketAccept(Native Method) at java.net.PlainSocketImpl.accept(PlainSocketImpl.java:384) - locked <0x23a40168> (a java.net.SocksSocketImpl) at java.net.ServerSocket.implAccept(ServerSocket.java:453) at java.net.ServerSocket.accept(ServerSocket.java:421) at org.apache.tomcat.util.net.DefaultServerSocketFactory.acceptSocket(DefaultServerSocketFactory.java:61) at org.apache.tomcat.util.net.JIoEndpoint$Acceptor.run(JIoEndpoint.java:310) at java.lang.Thread.run(Thread.java:619) "ContainerBackgroundProcessor[StandardEngine[Catalina]]" daemon prio=6 tid=0x051c9800 nid=0x152c waiting on condition [0x0452f000..0x0452fc68] java.lang.Thread.State: TIMED_WAITING (sleeping) at java.lang.Thread.sleep(Native Method) at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run(ContainerBase.java:1579) at java.lang.Thread.run(Thread.java:619) "Thread-1" daemon prio=2 tid=0x04638c00 nid=0x1360 in Object.wait() [0x044df000..0x044dfce8] java.lang.Thread.State: TIMED_WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on <0x23b87d30> (a EDU.oswego.cs.dl.util.concurrent.ClockDaemon) at EDU.oswego.cs.dl.util.concurrent.ClockDaemon.nextTask(ClockDaemon.java:328) - locked <0x23b87d30> (a EDU.oswego.cs.dl.util.concurrent.ClockDaemon) at EDU.oswego.cs.dl.util.concurrent.ClockDaemon$RunLoop.run(ClockDaemon.java:362) at java.lang.Thread.run(Thread.java:619) "ElementEventQueue.QProcessor-1" daemon prio=6 tid=0x050f2800 nid=0x17d0 in Object.wait() [0x0442f000..0x0442fd68] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on <0x23b81398> (a java.lang.Object) at java.lang.Object.wait(Object.java:485) at org.apache.jcs.engine.control.event.ElementEventQueue.take(ElementEventQueue.java:181) - locked <0x23b81398> (a java.lang.Object) at org.apache.jcs.engine.control.event.ElementEventQueue.access$300(ElementEventQueue.java:35) at org.apache.jcs.engine.control.event.ElementEventQueue$QProcessor.run(ElementEventQueue.java:245) "Low Memory Detector" daemon prio=6 tid=0x0215c800 nid=0x1370 runnable [0x00000000..0x00000000] java.lang.Thread.State: RUNNABLE "CompilerThread0" daemon prio=10 tid=0x02156400 nid=0x758 waiting on condition [0x00000000..0x0433f890] java.lang.Thread.State: RUNNABLE "Attach Listener" daemon prio=10 tid=0x02155400 nid=0x14f4 waiting on condition [0x00000000..0x00000000] java.lang.Thread.State: RUNNABLE "Signal Dispatcher" daemon prio=10 tid=0x0214ac00 nid=0x151c runnable [0x00000000..0x00000000] java.lang.Thread.State: RUNNABLE "Finalizer" daemon prio=8 tid=0x02143000 nid=0x430 in Object.wait() [0x0424f000..0x0424fce8] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on <0x2394e760> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:116) - locked <0x2394e760> (a java.lang.ref.ReferenceQueue$Lock) at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:132) at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:159) "Reference Handler" daemon prio=10 tid=0x02141000 nid=0x510 in Object.wait() [0x0091f000..0x0091fc68] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) - waiting on <0x2394e7e8> (a java.lang.ref.Reference$Lock) at java.lang.Object.wait(Object.java:485) at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:116) - locked <0x2394e7e8> (a java.lang.ref.Reference$Lock) "main" prio=6 tid=0x0020a800 nid=0xef4 runnable [0x0025f000..0x0025fe28] java.lang.Thread.State: RUNNABLE at java.net.PlainSocketImpl.socketAccept(Native Method) at java.net.PlainSocketImpl.accept(PlainSocketImpl.java:384) - locked <0x23e18dc0> (a java.net.SocksSocketImpl) at java.net.ServerSocket.implAccept(ServerSocket.java:453) at java.net.ServerSocket.accept(ServerSocket.java:421) at org.apache.catalina.core.StandardServer.await(StandardServer.java:389) at org.apache.catalina.startup.Catalina.await(Catalina.java:642) at org.apache.catalina.startup.Catalina.start(Catalina.java:602) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:288) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:413) "VM Thread" prio=10 tid=0x0213fc00 nid=0xdc0 runnable "VM Periodic Task Thread" prio=10 tid=0x0215dc00 nid=0x1128 waiting on condition JNI global references: 781 i also attach my logback configuration: <?xml version="1.0" encoding="UTF-8"?> <configuration debug="true"> <appender name="stdout" class="ch.qos.logback.core.ConsoleAppender"> <layout class="ch.qos.logback.classic.PatternLayout"> <Pattern> Operator %X{client}: %d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} %L - %msg%n </Pattern> </layout> </appender>  <logger name="net.sf.jguard.core" additivity="false"> <level value="INFO" /> <appender-ref ref="stdout" />  </logger> <logger name="net.sf.jguard.core.authorization" additivity="false"> <level value="debug"/> <appender-ref ref="stdout" />  </logger> <logger name="net.sf.jguard.core.filters" additivity="false"> <level value="debug"/> <appender-ref ref="stdout" />  </logger> <logger name="net.sf.jguard.ext" additivity="false"> <level value="INFO" /> <appender-ref ref="stdout" />  </logger> <logger name="net.sf.jguard.jee" additivity="false"> <level value="INFO" /> <appender-ref ref="stdout" />  </logger> <logger name="net.sf.ehcache" additivity="false"> <level value="INFO" /> <appender-ref ref="stdout" />  </logger> <logger name="de.ims.core.db" additivity="false"> <level value="DEBUG" /> <appender-ref ref="stdout" />  </logger> <logger name="de.ims.core.db.util" additivity="false"> <level value="INFO" /> <appender-ref ref="stdout" />  </logger> <logger name="de.ims.core.db.jguard" additivity="false"> <level value="INFO" /> <appender-ref ref="stdout" />  </logger> <logger name="de.ims.core.db.DBUserImpl" additivity="false"> <level value="DEBUG" /> <appender-ref ref="stdout" />  </logger> <logger name="de.ims.core.db.DBGroupImpl" additivity="false"> <level value="DEBUG" /> <appender-ref ref="stdout" />  </logger> <logger name="de.ims.core.db.DBOperatorImpl" additivity="false"> <level value="INFO" /> <appender-ref ref="stdout" />  </logger> <logger name="de.ims.core.db.DBInstitutionImpl" additivity="false"> <level value="INFO" /> <appender-ref ref="stdout" />  </logger> <logger name="org.apache.jcs" additivity="false"> <level value="WARN" /> <appender-ref ref="stdout" />  </logger> <root>   <level value="DEBUG" /> <appender-ref ref="stdout" />  </root> </configuration> -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

4 10

[JIRA] Created: (LBCLASSIC-124) wrong Output for %contextName in SimpleSocketServer with PatternLayout
by Rick Janda (JIRA) 20 Apr '09

20 Apr '09

wrong Output for %contextName in SimpleSocketServer with PatternLayout ----------------------------------------------------------------------- Key: LBCLASSIC-124 URL: http://jira.qos.ch/browse/LBCLASSIC-124 Project: logback-classic Issue Type: Bug Components: Other Affects Versions: 0.9.15 Reporter: Rick Janda Assignee: Logback dev list Hello logback team, I found some unexpected behavior when trying to print out the log context name in the log message created by the SimpleSocketServer. %contextName in a PatternLayout of the SimpleSocketServer always creates "default" and not the context name submitted from the client. On the other side, context based discrimination works fine on the side of the SocketServer. Thus the context name seems to be correctly handed over to the SocketServer. Could you please have a look at this. Thank you in advance, Rick -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

1 0

[JIRA] Commented: (LBCORE-26) TimeBasedRollingPolicy append logs into a old log file, instead of rolling the log file.
by Pavel (JIRA) 19 Apr '09

19 Apr '09

[ http://jira.qos.ch/browse/LBCORE-26?page=com.atlassian.jira.plugin.system.i… ] Pavel commented on LBCORE-26: ----------------------------- I found the solution (or reason for wrong behavior) : in configuration file the setting for log file name <param name="File" value="filename.log" /> should appear BEFORE!!! the rollingPolicy entry <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy"> <FileNamePattern>logfile.%d{yyyy-MM-dd_HH-mm}.log.zip</FileNamePattern> <MaxHistory>30</MaxHistory> </rollingPolicy> > TimeBasedRollingPolicy append logs into a old log file, instead of rolling the log file. > ---------------------------------------------------------------------------------------- > > Key: LBCORE-26 > URL: http://jira.qos.ch/browse/LBCORE-26 > Project: logback-core > Issue Type: Bug > Components: Rolling > Affects Versions: unspecified > Environment: Operating System: All > Platform: All > Reporter: Tsutomu YANO > Assignee: Logback dev list > Priority: Critical > Fix For: 0.9.12 > > > If you use TimeBasedRollingPolicy to rollover a log file and no log wasn't wrote into the log beyond the timing of rollover, and if you restart your application, the log file doesn't roll, then new log will be appended into old log file. > EVIDENCE: > 1. in logback.xml, set your FileNamePattern like 'log.%d{yyyy-MM-dd_HH-mm}.log'. > 2. Simply do a kind of thing, which will make some logs into your log file. > 3. Wait for some minutes. > 4. restart your application. > 5. do a kind of thing, which will make some logs into your log file. > the FileNamePattern is 'log.%d{yyyy-MM-dd_HH-mm}.log', so the log file will be roll every minutes. On case 5 of above example, the log file should be roll over, because some minutes already have passed after last logs wrote into the log file. But the file didn't be roll overed. > THE CAUSE: > In start() method of TimeBasedRollingPolicy, you initialize a variable 'lastCheck' to System.currentTimeStamp(). So if you restart your application, the last check time will be set to just NOW. > you should initialize the variable to a last modified time of a current log file. > See below source code. from '//modified by Tsutomu YANO' to '//until here'. > SOURCE: > public void start() { > // set the LR for our utility object > util.setContext(this.context); > compress.setContext(this.context); > // find out period from the filename pattern > if (fileNamePatternStr != null) { > fileNamePattern = new FileNamePattern(fileNamePatternStr, this.context); > determineCompressionMode(); > } else { > addWarn(FNP_NOT_SET); > addWarn(SEE_FNP_NOT_SET); > throw new IllegalStateException(FNP_NOT_SET + SEE_FNP_NOT_SET); > } > DateTokenConverter dtc = fileNamePattern.getDateTokenConverter(); > if (dtc == null) { > throw new IllegalStateException("FileNamePattern [" + fileNamePattern.getPattern() + "] does not contain a valid DateToken"); > } > int len = fileNamePatternStr.length(); > switch (compressionMode) { > case Compress.GZ: > activeFileNamePattern = new FileNamePattern(fileNamePatternStr.substring(0, len - 3), this.context); > break; > case Compress.ZIP: > activeFileNamePattern = new FileNamePattern(fileNamePatternStr.substring(0, len - 4), this.context); > break; > case Compress.NONE: > activeFileNamePattern = fileNamePattern; > } > addInfo("Will use the pattern " + activeFileNamePattern + " for the active file"); > rc = new RollingCalendar(); > rc.init(dtc.getDatePattern()); > addInfo("The date pattern is '" + dtc.getDatePattern() + "' from file name pattern '" + fileNamePattern.getPattern() + "'."); > rc.printPeriodicity(this); > > //modified by Tsutomu YANO > //if a current log file exists, initialize a 'lastCheck' variable to the > //last modified date of the file. > File currentFile = new File(getParentFileName()); > if(currentFile.exists() && currentFile.canRead()) { > lastCheck.setTime(currentFile.lastModified()); > } else { > // currentTime = System.currentTimeMillis(); > lastCheck.setTime(getCurrentTime()); > } > //until here > > nextCheck = rc.getNextCheckMillis(lastCheck); > // Date nc = new Date(); > // nc.setTime(nextCheck); > } -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

1 0

Using Thread to monitored TimeBasedRollingPolicy...!
by boss134 03 Apr '09

03 Apr '09

Dear sir, Yesterday night, i tried TimeBasedRollingPolicy class to logs the my code part. i used below configuration code in XML and after, used a single Thread to runs full night... When i see today morning, file created (myDebug.2009-04-02.zip) successfully. i extracted zip file after i verified yesterday log file. But, When see a current log file it keeps both logs (means yesterday and today logs). Actually this current log should contain today log only... i don't where am doing problem.... Please HELP me out... <appender name="FILEDEBUG" class="ch.qos.logback.core.rolling.RollingFileAppender"> <file>Debug/myDebug.log</file> <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy"> <FileNamePattern>myDebug.%d.zip</FileNamePattern> <MaxHistory>60</MaxHistory> </rollingPolicy> <filter class="ch.qos.logback.classic.filter.LevelFilter"> <level>DEBUG</level> <onMatch>ACCEPT</onMatch> <onMismatch>DENY</onMismatch> </filter> <layout class="ch.qos.logback.classic.PatternLayout"> <Pattern>%date %level [%thread] %logger{10} [%file:%line] %msg%n</Pattern> </layout> </appender> Thank you, boss134 -- View this message in context: http://www.nabble.com/Using-Thread-to-monitored-TimeBasedRollingPolicy...%2… Sent from the Logback Dev mailing list archive at Nabble.com.

2 4

More than one filter in Appender
by boss134 03 Apr '09

03 Apr '09

is it possible to support more than one filter in Appender...? -- View this message in context: http://www.nabble.com/More-than-one-filter-in-Appender-tp22862398p22862398.… Sent from the Logback Dev mailing list archive at Nabble.com.

2 2

[JIRA] Created: (LBCLASSIC-123) SocketNode constructor blocks due to ObjectInputStream creation
by Richard Fearn (JIRA) 02 Apr '09

02 Apr '09

SocketNode constructor blocks due to ObjectInputStream creation --------------------------------------------------------------- Key: LBCLASSIC-123 URL: http://jira.qos.ch/browse/LBCLASSIC-123 Project: logback-classic Issue Type: Bug Components: Other Affects Versions: 0.9.16 Environment: Using Logback 0.9.9, but problem is still present in trunk Reporter: Richard Fearn Assignee: Logback dev list Priority: Minor SocketNode implements Runnable, the implication being that a SocketNode can be run in its own thread like this: while (true) { // accept a client connection new Thread(new SocketNode(...)).start(); } However the SocketNode creates an ObjectInputStream using the socket's input stream, which blocks waiting for the stream header - so the constructor does not return, the thread cannot start and the loop shown above cannot continue until data has been received from the client. Typically a client would connect and immediately send data, so this wouldn't be an issue, but if someone just telnets to the log server and doesn't send any data, the above loop will block and prevent other clients' log messages from being processed. It would be better if the ObjectInputStream was created in the run() method to avoid the constructor blocking. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

1 0