Connection leaks with DBAppender and GlassFish?
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--tp3213... Sent from the Logback User mailing list archive at Nabble.com.
How many connections are leaked? Over what time period? Could it be logback gets one connection and keeps it for all time, until the log is closed. That's not really a leak, but just confuses the leak detection. On 25 Jul 2011, at 14:22, Stephan Vollmer-2 <svollmer@gmx.de> wrote:
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--tp3213... Sent from the Logback User mailing list archive at Nabble.com.
_______________________________________________ Logback-user mailing list Logback-user@qos.ch http://qos.ch/mailman/listinfo/logback-user
David Roussel wrote:
How many connections are leaked? Over what time period? Could it be logback gets one connection and keeps it for all time, until the log is closed. That's not really a leak, but just confuses the leak detection.
Sorry for the late reply. It is only 1 connection that is considered as leaked. I did not know that Logback allocates a connection when it is needed and then keeps it open all the time. I thought that the connection would be closed afterwards. If the former is true, then I need to turn off connection leak detection in the application server configuration. -- View this message in context: http://old.nabble.com/Connection-leaks-with-DBAppender-and-GlassFish--tp3213... Sent from the Logback User mailing list archive at Nabble.com.
participants (2)
-
David Roussel -
Stephan Vollmer-2