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

[JIRA] Created: (LBCLASSIC-125) NoClassDefFoundError in PackagingDataCalculator.loadClass()
by Roland Klein (JIRA) 22 Jul '09

22 Jul '09

NoClassDefFoundError in PackagingDataCalculator.loadClass() ----------------------------------------------------------- Key: LBCLASSIC-125 URL: http://jira.qos.ch/browse/LBCLASSIC-125 Project: logback-classic Issue Type: Bug Affects Versions: 0.9.15 Environment: jdk 1.6 (build 1.6.0_10-b33) jboss 4.2.2ga Reporter: Roland Klein Assignee: Logback dev list In an EJB Client/Server Environment the loadClass() method could fail, because the vm issues a NoClassDefFoundError. And there is no corresponding catch, so the whole logging fails and throws a NoClassDefFoundError. -- 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-109) Logger allows TRACE messages when reset to DEBUG
by Andrew Ruch (JIRA) 21 Jul '09

21 Jul '09

Logger allows TRACE messages when reset to DEBUG ------------------------------------------------ Key: LBCLASSIC-109 URL: http://jira.qos.ch/browse/LBCLASSIC-109 Project: logback-classic Issue Type: Bug Environment: SLF4J 1.5.6 and Logback 0.9.15 Reporter: Andrew Ruch Assignee: Logback dev list Priority: Minor When reconfiguring the LoggerContext, TRACE messages are logged even when the Logger level is set to DEBUG. As Ceki pointed out, the following test reproduces the issue. @Test public void levelResetTest() { LoggerContext loggerContext = new LoggerContext(); Logger root = loggerContext.getLogger(LoggerContext.ROOT_NAME); root.setLevel(Level.TRACE); assertTrue(root.isTraceEnabled()); loggerContext.reset(); //Logger is reset to DEBUG assertFalse(root.isTraceEnabled()); <-- assertion fails assertTrue(root.isDebugEnabled()); } -- 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 1

[JIRA] Created: (LBCORE-59) Support for reconfiguration at runtime
by Michael Osipov (JIRA) 20 Jul '09

20 Jul '09

Support for reconfiguration at runtime -------------------------------------- Key: LBCORE-59 URL: http://jira.qos.ch/browse/LBCORE-59 Project: logback-core Issue Type: New Feature Components: Joran Affects Versions: 0.9.9 Reporter: Michael Osipov Assignee: Logback dev list Joran should support reconfiguration at runime like log4j's DOMConfigurator#configureAndWatch. -- 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 8

[JIRA] Created: (LBCORE-94) Rollover at launch time
by Ceki Gulcu (JIRA) 08 Jul '09

08 Jul '09

Rollover at launch time ----------------------- Key: LBCORE-94 URL: http://jira.qos.ch/browse/LBCORE-94 Project: logback-core Issue Type: Bug Components: Rolling Affects Versions: 0.9.15 Reporter: Ceki Gulcu Assignee: Ceki Gulcu Rollover does not occur for old files when short lived application is restarted. This issue is related to LBCORE-26.However, the solution implemented in LBCORE-26 works if the RollingFileAppender has the File property set. This is not always the case. For instance <appender name="FILE" class="ch.qos.logback.core.rolling.RollingFileAppender"> <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy"> <FileNamePattern>test.%d.log.zip</FileNamePattern> </rollingPolicy> <layout/> </appender> <root level="info"> <appender-ref ref="FILE"/> </root> Problem originally reported by Ch Pasha. See also http://www.qos.ch/pipermail/logback-user/2009-March/001030.html -- 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 4

[JIRA] Created: (LBCORE-60) Allow rolling based on time or file size
by Szel Zoltan (JIRA) 02 Jul '09

02 Jul '09

Allow rolling based on time or file size ---------------------------------------- Key: LBCORE-60 URL: http://jira.qos.ch/browse/LBCORE-60 Project: logback-core Issue Type: New Feature Components: Appender Affects Versions: 0.9.9 Reporter: Szel Zoltan Assignee: Logback dev list The rolling grouping file appender allows to roll over on a specific interval(TimeBasedRollingPolicy) or when the log file has reached a specific file size. But unfortunately Logback does not support both to use together. For example if i want to roll over every day but i also want to roll the file when it is greater than 100MB. Please consider adding this feature to Logback and feel free to contact me if further clarification is required. Thanks, Zoltan Szel -- 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 9

[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] Closed: (LBCORE-63) Deadlock when running on multiple core processors
by Ceki Gulcu (JIRA) 28 May '09

28 May '09

[ http://jira.qos.ch/browse/LBCORE-63?page=com.atlassian.jira.plugin.system.i… ] Ceki Gulcu closed LBCORE-63. ---------------------------- Resolution: Won't Fix This issue is tainted by the fact that the eclipse console plug-in is being used. If you are really concerned about a deadlock issue, please open a new and separate issue. Suppling a test case would be most appropriate. In the mean time, as forewarned on March the 23rd, I am closing this issue. > Deadlock when running on multiple core processors > ------------------------------------------------- > > Key: LBCORE-63 > URL: http://jira.qos.ch/browse/LBCORE-63 > Project: logback-core > Issue Type: Sub-task > Affects Versions: 0.9.9 > Environment: Operating System: Windows > Platform: PC > Reporter: Toni Heimala > Assignee: Ceki Gulcu > Priority: Blocker > Attachments: AppenderBaseLock.patch, patch.txt, patch2.txt, patch3.txt > > > When you run logging into same file from many threads on a system that has more than one physical processor (Dual Core for example), a deadlock will occur after a while. This can not be reproduced on HyperThreading processors. Here's an example program that will demonstrate the behavior: > ----------------------------- > Main.java > ----------------------------- > import java.util.Date; > import java.util.concurrent.ScheduledThreadPoolExecutor; > import java.util.concurrent.TimeUnit; > import org.slf4j.Logger; > import org.slf4j.LoggerFactory; > import ch.qos.logback.classic.LoggerContext; > import ch.qos.logback.classic.joran.JoranConfigurator; > import ch.qos.logback.core.joran.spi.JoranException; > public class Main extends Thread > { > private final static String LOGGER_CONFIGURATION_FILE = "logger.xml"; > private final Logger logger = LoggerFactory.getLogger(Main.class); > > private final long start; > > public Main() > throws JoranException > { > start = new Date().getTime(); > LoggerContext lc = (LoggerContext)LoggerFactory.getILoggerFactory(); > JoranConfigurator configurator = new JoranConfigurator(); > lc.shutdownAndReset(); > configurator.setContext(lc); > configurator.doConfigure(LOGGER_CONFIGURATION_FILE); > } > > public void start() > { > ScheduledThreadPoolExecutor ex1 = new ScheduledThreadPoolExecutor(1); > ScheduledThreadPoolExecutor ex2 = new ScheduledThreadPoolExecutor(1); > ScheduledThreadPoolExecutor ex3 = new ScheduledThreadPoolExecutor(1); > ScheduledThreadPoolExecutor ex4 = new ScheduledThreadPoolExecutor(1); > ScheduledThreadPoolExecutor ex5 = new ScheduledThreadPoolExecutor(1); > ex1.scheduleAtFixedRate(new Task("EX1"), 10, 10, TimeUnit.MICROSECONDS); > ex2.scheduleAtFixedRate(new Task("EX2"), 10, 10, TimeUnit.MICROSECONDS); > ex3.scheduleAtFixedRate(new Task("EX3"), 10, 10, TimeUnit.MICROSECONDS); > ex4.scheduleAtFixedRate(new Task("EX4"), 10, 10, TimeUnit.MICROSECONDS); > ex5.scheduleAtFixedRate(new Task("EX5"), 10, 10, TimeUnit.MICROSECONDS); > > super.start(); > } > > public void run() > { > try > { > while(true) > { > logger.debug("[MAIN] {}", new Date().getTime() - start); > Thread.sleep(10); > } > } > catch (InterruptedException e) > { > logger.info("[MAIN]: Interrupted: {}", e.getMessage()); > } > } > > public static void main(String[] args) > { > try > { > Main main = new Main(); > main.start(); > } > catch (JoranException e) > { > System.out.println("Failed to load application: " + e.getMessage()); > } > } > } > ------------------------------- > Task.java > ------------------------------- > import java.util.Date; > import org.slf4j.Logger; > import org.slf4j.LoggerFactory; > public class Task implements Runnable > { > private final Logger logger = LoggerFactory.getLogger(Task.class); > private final Logger logger_main = LoggerFactory.getLogger(Main.class); > private final String name; > private final long start; > > public Task(final String name) > { > this.name = name; > start = new Date().getTime(); > } > public void run() > { > logger.debug("[{}] {}", name, new Date().getTime() - start); > logger_main.debug("[MAIN] - [{}] {}", name, new Date().getTime() - start); > } > } -- 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] 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