[logback-user] Connection leaks with DBAppender and GlassFish?

[Stephan Vollmer-2]

Hi,

I use Logback 0.9.29 and the DBAppender to log error messages into a
database. The Java EE 6 application runs with GlassFish 3.1 and uses the
JNDIConnectionSource to obtain a database connection. I have created a
separate database connection pool within GlassFish that is only used for
Logback. This pool also has connection leak detection enabled.

When the connection leak timeout has passed, the server log has the
following error message:

[#|2011-07-25T12:18:26.217+0200|INFO|glassfish3.1.1|javax.enterprise.resource.resourceadapter.com.su
n.enterprise.resource.pool|_ThreadID=24;_ThreadName=Thread-2;|Reclaiming the
leaked connection of
pool [ loggerPool ] and destroying it so as to avoid both the application
that leaked the connection and
any other request that can potentially acquire the same connection from the
pool end up using the
connection at the same time|#]

[#|2011-07-25T12:18:27.841+0200|WARNING|glassfish3.1.1|javax.enterprise.resource.resourceadapter.com
.sun.enterprise.resource.pool|_ThreadID=24;_ThreadName=Thread-2;|A potential
connection leak 
detected for connection pool loggerPool. The stack trace of the thread is
provided below :
com.sun.enterprise.resource.pool.ConnectionPool.setResourceStateToBusy(ConnectionPool.java:324)
com.sun.enterprise.resource.pool.ConnectionPool.getResourceFromPool(ConnectionPool.java:758)
com.sun.enterprise.resource.pool.ConnectionPool.getUnenlistedResource(ConnectionPool.java:632)
com.sun.enterprise.resource.pool.ConnectionPool.internalGetResource(ConnectionPool.java:526)
com.sun.enterprise.resource.pool.ConnectionPool.getResource(ConnectionPool.java:381)
com.sun.enterprise.resource.pool.PoolManagerImpl.getResourceFromPool(PoolManagerImpl.java:242)
com.sun.enterprise.resource.pool.PoolManagerImpl.getResource(PoolManagerImpl.java:167)
com.sun.enterprise.connectors.ConnectionManagerImpl.getResource(ConnectionManagerImpl.java:338)
com.sun.enterprise.connectors.ConnectionManagerImpl.internalGetConnection(ConnectionManagerImpl.java:301)
com.sun.enterprise.connectors.ConnectionManagerImpl.allocateConnection(ConnectionManagerImpl.java:190)
com.sun.enterprise.connectors.ConnectionManagerImpl.allocateConnection(ConnectionManagerImpl.java:165)
com.sun.enterprise.connectors.ConnectionManagerImpl.allocateConnection(ConnectionManagerImpl.java:160)
com.sun.gjc.spi.base.DataSource.getConnection(DataSource.java:113)
ch.qos.logback.core.db.JNDIConnectionSource.getConnection(JNDIConnectionSource.java:69)
ch.qos.logback.core.db.ConnectionSourceBase.discoverConnnectionProperties(ConnectionSourceBase.java:47)
ch.qos.logback.core.db.JNDIConnectionSource.start(JNDIConnectionSource.java:54)
ch.qos.logback.core.joran.action.NestedComplexPropertyIA.end(NestedComplexPropertyIA.java:167)
ch.qos.logback.core.joran.spi.Interpreter.callEndAction(Interpreter.java:315)
ch.qos.logback.core.joran.spi.Interpreter.endElement(Interpreter.java:194)
ch.qos.logback.core.joran.spi.Interpreter.endElement(Interpreter.java:180)
ch.qos.logback.core.joran.spi.EventPlayer.play(EventPlayer.java:52)
ch.qos.logback.core.joran.spi.Interpreter.play(Interpreter.java:332)
ch.qos.logback.core.joran.GenericConfigurator.doConfigure(GenericConfigurator.java:132)
ch.qos.logback.core.joran.GenericConfigurator.doConfigure(GenericConfigurator.java:93)
ch.qos.logback.core.joran.GenericConfigurator.doConfigure(GenericConfigurator.java:52)
ch.qos.logback.classic.util.ContextInitializer.configureByResource(ContextInitializer.java:77)
ch.qos.logback.classic.util.ContextInitializer.autoConfig(ContextInitializer.java:150)
ch.qos.logback.classic.selector.ContextJNDISelector.getLoggerContext(ContextJNDISelector.java:108)
org.slf4j.impl.StaticLoggerBinder.getLoggerFactory(StaticLoggerBinder.java:108)
org.slf4j.LoggerFactory.getILoggerFactory(LoggerFactory.java:273)
org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:241)
org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:254)
de.mycompany.mb.config.WebServiceConfigurationProvider.<init>
(WebServiceConfigurationProvider.java:16)
sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
java.lang.reflect.Constructor.newInstance(Constructor.java:513)
java.lang.Class.newInstance0(Class.java:355)


My logback.xml:

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
    <contextName>${project.artifactId}</contextName>
    <property name="application-name" value="${project.artifactId}" />
    <jmxConfigurator />

    <appender name="DB" class="ch.qos.logback.classic.db.DBAppender">
        <filter class="ch.qos.logback.classic.filter.ThresholdFilter">
            <level>ERROR</level>
        </filter>
        <connectionSource
class="ch.qos.logback.core.db.JNDIConnectionSource">
            
        </connectionSource>
    </appender>

    <root>
        <level value="DEBUG" />
        <appender-ref ref="DB" />
    </root>
</configuration>


The Java code is very simple:

public class LogbackTest {
    private final Logger logger =
LoggerFactory.getLogger(LogbackTest.class);

    @PostConstruct
    public void init() throws IOException {
        logger.error("Test error message");
    }
}


Is there probably a problem with my configuration or the way I use Logback?
What can I do to avoid the connection leak error messages? I could simply
disable connection leak detection, but I don't think that is the right way
to deal with it.

Thanks in advance for your help!
Stephan
-- 
View this message in context: http://old.nabble.com/Connection-leaks-with-DBAppender-and-GlassFish--tp32131274p32131274.html
Sent from the Logback User mailing list archive at Nabble.com.