[ http://jira.qos.ch/browse/LBCLASSIC-148?page=com.atlassian.jira.plugin.syste... ] Ceki Gulcu commented on LBCLASSIC-148: -------------------------------------- Thank you for this report and the accompanying tests cases. They were very helpful in tracking down the problem. C3p0 has its own logging API which delegates to log4j if it is detected on the class path. When you place log4j-over-slf4j.jar, c3p0 detects "log4j" which then delegates to SLF4J. I've attached a log file showing the logging output generated by c3p0. Given that DBAppender in your precise configuration is instructed to use c3p0, whenever c3p0 code living in a different thread attempts to log, there is a potential deadlock situation. I find c3p0 code messy, especially regarding logging. My suggestion would be to either 1) silence logs generated by "com.mchange.v2" loggers and its children by adding the following to the config file <logger name="com.mchange.v2" level="OFF"/> or 2) add a file appender to "com.mchange.v2" logger with the additivity flag set to false. <logger name="com.mchange.v2" additivity="false"> <appender-ref name="any appender other than DBAppender"> </logger> HTH
Deadlock with DBAppender ------------------------
Key: LBCLASSIC-148 URL: http://jira.qos.ch/browse/LBCLASSIC-148 Project: logback-classic Issue Type: Bug Affects Versions: 0.917 Environment: MacBook Pro 17" Intel Core 2 Duo 2.33 GHz OS X 10.5.7 (9J61) java version "1.6.0_13" slf4j 1.5.8 c3p0 0.9.1.2 Reporter: Mel T. Assignee: Ceki Gulcu Priority: Critical Attachments: logback2-works.xml, logback2.xml, MainTest.java
A deadlock occurs when running the attached application. For this lock to occur, we need to: - load a configuration other than the default in java app. - not have any default logback.xml in the classpath.
- have these jars in the classpath c3p0-0.9.1.2.jar logback-core-0.9.17.jar logback-classic-0.9.17.jar log4j-over-slf4j-1.5.8.jar slf4j-api-1.5.8.jar mysql.jar - Place attached the logback2.xml file in the same package as the attached MainTest class. - adapt the logback2.xml file to your DB schema. (note that you do not need to have the DB tables created for the lock to occur, but the test is more conclusive if you have a valid DB connection and schema.) - Execute this java -cp ".:../c3p0-0.9.1.2.jar:../logback-core-0.9.17.jar:../logback-classic-0.9.17.jar:../log4j-over-slf4j-1.5.8.jar:../slf4j-api-1.5.8.jar:../mysql.jar" MainTest The application should output the logger status and hang. Workaround: - Do not include log4j-over-slf4j in the classpath, - or add a default logback.xml that will be loaded first (just copy and rename logback2.xml in same default package) - or use the attached logback2-works.xml instead of logback2.xml (modify MainTest to load that file instead.) In this last one, the change is that the DB appender is only used in a logger element instead of the root. I did not spend the time to look at the cause of this locking problem as the workarounds allow me to move on. So I hope this really belong in jira, and not a config/usage error on my part. -- Mel T.
-- 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