spring oder hibernate-Verbindung Leck

Bin ich mit spring mit hibernate auf eine webapp (hibernate-core-4.3.8.Endgültig und Frühjahr 3.2.11.RELEASE).
Ich bin mit hikaricp (v 2.2.5), die als Verbindungs-pool, impl, erkennt eine Verbindung undicht und druckt den stacktrace unten. Ich bin mit spring deklaratives Transaktions-Abgrenzung, so dass ich davon ausgehen, das management und bereinigen von Ressourcen erfolgt, die von spring/hibernate. Also, ich denke, entweder spring oder hibernate ist die Ursache der erkannten Verbindung undicht.

grundsätzlich gibt es timer, die, wenn Sie abgefeuert, ruft eine spring-bean gekennzeichnet mit @Transactional-annotation.

 @Transactional public class InvoiceCycleExporter {
public runExportInvoiceCycleJob(){
  //this method when called is **sometimes** leaking a connection ....
} }

können Sie mir bitte helfen, verfolgen Sie die Quelle der Verbindung austreten.

meine appcontext.xml config für die datasource, connection pool, entitymanager unter

 <bean id="hikariConfig" class="com.zaxxer.hikari.HikariConfig">
    <property name="jdbcUrl" value="${jdbc.url}"/>
    <property name="username" value="${jdbc.user}"/>
    <property name="password" value="${jdbc.password}"/>
    <property name="maximumPoolSize" value="${jdbc.maximumPoolSize}"/>
    <property name="driverClassName" value="org.postgresql.Driver"/>
    <property name="leakDetectionThreshold" value="${jdbc.leakDetectionThreshold}"/>
</bean>

<bean id="dataSource" class="com.zaxxer.hikari.HikariDataSource" destroy-method="shutdown">
    <constructor-arg ref="hikariConfig"/>
</bean>

<bean id="entityManagerFactory" class="org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean">        
    <property name="dataSource" ref="dataSource"/>
    <property name="persistenceUnitName" value="velosPU"/>
    <property name="persistenceXmlLocation" value="classpath:META-INF/persistence.xml"/>       //more stuff ....   
 </bean>

stacktrace unten:

2015-01-13 14:25:00.123 [Hikari Housekeeping Timer (pool HikariPool-0)] WARN  com.zaxxer.hikari.util.LeakTask - Connection leak detection triggered, stack trace follows
java.lang.Exception: null
        at org.hibernate.engine.jdbc.connections.internal.DatasourceConnectionProviderImpl.getConnection(DatasourceConnectionProviderImpl.java:139) ~[hibernate-core-4.3.8.Final.jar:4.3.8.Final]
        at org.hibernate.internal.AbstractSessionImpl$NonContextualJdbcConnectionAccess.obtainConnection(AbstractSessionImpl.java:380) ~[hibernate-core-4.3.8.Final.jar:4.3.8.Final]
        at org.hibernate.engine.jdbc.internal.LogicalConnectionImpl.obtainConnection(LogicalConnectionImpl.java:228) ~[hibernate-core-4.3.8.Final.jar:4.3.8.Final]
        at org.hibernate.engine.jdbc.internal.LogicalConnectionImpl.getConnection(LogicalConnectionImpl.java:171) ~[hibernate-core-4.3.8.Final.jar:4.3.8.Final]
        at org.hibernate.engine.transaction.internal.jdbc.JdbcTransaction.doBegin(JdbcTransaction.java:67) ~[hibernate-core-4.3.8.Final.jar:4.3.8.Final]
        at org.hibernate.engine.transaction.spi.AbstractTransactionImpl.begin(AbstractTransactionImpl.java:162) ~[hibernate-core-4.3.8.Final.jar:4.3.8.Final]
        at org.hibernate.internal.SessionImpl.beginTransaction(SessionImpl.java:1435) ~[hibernate-core-4.3.8.Final.jar:4.3.8.Final]
        at org.hibernate.jpa.internal.TransactionImpl.begin(TransactionImpl.java:61) ~[hibernate-entitymanager-4.3.8.Final.jar:4.3.8.Final]
        at org.springframework.orm.jpa.DefaultJpaDialect.beginTransaction(DefaultJpaDialect.java:70) ~[spring-orm-3.2.11.RELEASE.jar:3.2.11.RELEASE]
        at org.springframework.orm.jpa.vendor.HibernateJpaDialect.beginTransaction(HibernateJpaDialect.java:61) ~[spring-orm-3.2.11.RELEASE.jar:3.2.11.RELEASE]
        at org.springframework.orm.jpa.JpaTransactionManager.doBegin(JpaTransactionManager.java:378) ~[spring-orm-3.2.11.RELEASE.jar:3.2.11.RELEASE]
        at org.springframework.transaction.support.AbstractPlatformTransactionManager.getTransaction(AbstractPlatformTransactionManager.java:372) ~[spring-tx-3.2.11.RELEASE.jar:3.2.11.RELEASE]
        at org.springframework.transaction.interceptor.TransactionAspectSupport.createTransactionIfNecessary(TransactionAspectSupport.java:417) ~[spring-tx-3.2.11.RELEASE.jar:3.2.11.RELEASE]
        at org.springframework.transaction.interceptor.TransactionAspectSupport.invokeWithinTransaction(TransactionAspectSupport.java:255) ~[spring-tx-3.2.11.RELEASE.jar:3.2.11.RELEASE]
        at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:94) ~[spring-tx-3.2.11.RELEASE.jar:3.2.11.RELEASE]
        at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172) ~[spring-aop-3.2.11.RELEASE.jar:3.2.11.RELEASE]
        at org.springframework.aop.framework.CglibAopProxy$DynamicAdvisedInterceptor.intercept(CglibAopProxy.java:633) ~[spring-aop-3.2.11.RELEASE.jar:3.2.11.RELEASE]
        at com.ukfuels.velos.services.bl.internalinterface.impl.bl.invoicing.**InvoiceCycleExporter (this is the spring bean marked with the transactional annotation)**$$EnhancerBySpringCGLIB$$519c078f.runExportInvoiceCycleJob(<generated>) ~[spring-core-3.2.11.RELEASE.jar:na]
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[na:1.7.0_65]
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) ~[na:1.7.0_65]
        at org.apache.camel.component.bean.BeanProcessor.process(BeanProcessor.java:67) ~[camel-core-2.11.4.jar:2.11.4]
        at org.apache.camel.impl.ProcessorEndpoint.onExchange(ProcessorEndpoint.java:103) ~[camel-core-2.11.4.jar:2.11.4]
        at org.apache.camel.impl.ProcessorEndpoint$1.process(ProcessorEndpoint.java:71) ~[camel-core-2.11.4.jar:2.11.4]
        at org.apache.camel.util.AsyncProcessorConverterHelper$ProcessorToAsyncProcessorBridge.process(AsyncProcessorConverterHelper.java:61) ~[camel-core-2.11.4.jar:2.11.4]
        at org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHelper.java:73) ~[camel-core-2.11.4.jar:2.11.4]
        at org.apache.camel.processor.SendProcessor$2.doInAsyncProducer(SendProcessor.java:122) ~[camel-core-2.11.4.jar:2.11.4]
        at org.apache.camel.impl.ProducerCache.doInAsyncProducer(ProducerCache.java:298) ~[camel-core-2.11.4.jar:2.11.4]
        at org.apache.camel.processor.SendProcessor.process(SendProcessor.java:117) ~[camel-core-2.11.4.jar:2.11.4]
        at org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHelper.java:73) ~[camel-core-2.11.4.jar:2.11.4]
        at org.apache.camel.processor.DelegateAsyncProcessor.processNext(DelegateAsyncProcessor.java:99) ~[camel-core-2.11.4.jar:2.11.4]
        at org.apache.camel.processor.DelegateAsyncProcessor.process(DelegateAsyncProcessor.java:90) ~[camel-core-2.11.4.jar:2.11.4]
        at org.apache.camel.management.InstrumentationProcessor.process(InstrumentationProcessor.java:72) ~[camel-core-2.11.4.jar:2.11.4]
        at org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHelper.java:73) ~[camel-core-2.11.4.jar:2.11.4]
        at org.apache.camel.processor.DelegateAsyncProcessor.processNext(DelegateAsyncProcessor.java:99) ~[camel-core-2.11.4.jar:2.11.4]
        at org.apache.camel.processor.DelegateAsyncProcessor.process(DelegateAsyncProcessor.java:90) ~[camel-core-2.11.4.jar:2.11.4]
        at org.apache.camel.processor.interceptor.BacklogTracerInterceptor.process(BacklogTracerInterceptor.java:84) ~[camel-core-2.11.4.jar:2.11.4]
        at org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHelper.java:73) ~[camel-core-2.11.4.jar:2.11.4]
        at org.apache.camel.processor.DelegateAsyncProcessor.processNext(DelegateAsyncProcessor.java:99) ~[camel-core-2.11.4.jar:2.11.4]
        at org.apache.camel.processor.DelegateAsyncProcessor.process(DelegateAsyncProcessor.java:90) ~[camel-core-2.11.4.jar:2.11.4]
        at org.apache.camel.processor.interceptor.TraceInterceptor.process(TraceInterceptor.java:91) ~[camel-core-2.11.4.jar:2.11.4]
        at org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHelper.java:73) ~[camel-core-2.11.4.jar:2.11.4]
        at org.apache.camel.processor.RedeliveryErrorHandler.processErrorHandler(RedeliveryErrorHandler.java:391) ~[camel-core-2.11.4.jar:2.11.4]
        at org.apache.camel.processor.RedeliveryErrorHandler.process(RedeliveryErrorHandler.java:273) ~[camel-core-2.11.4.jar:2.11.4]
        at org.apache.camel.processor.RouteContextProcessor.processNext(RouteContextProcessor.java:46) ~[camel-core-2.11.4.jar:2.11.4]
        at org.apache.camel.processor.DelegateAsyncProcessor.process(DelegateAsyncProcessor.java:90) ~[camel-core-2.11.4.jar:2.11.4]
        at org.apache.camel.processor.interceptor.DefaultChannel.process(DefaultChannel.java:335) ~[camel-core-2.11.4.jar:2.11.4]
        at org.apache.camel.processor.RouteContextProcessor.processNext(RouteContextProcessor.java:46) ~[camel-core-2.11.4.jar:2.11.4]
        at org.apache.camel.processor.DelegateAsyncProcessor.process(DelegateAsyncProcessor.java:90) ~[camel-core-2.11.4.jar:2.11.4]
        at org.apache.camel.processor.UnitOfWorkProcessor.processAsync(UnitOfWorkProcessor.java:150) ~[camel-core-2.11.4.jar:2.11.4]
        at org.apache.camel.processor.UnitOfWorkProcessor.process(UnitOfWorkProcessor.java:117) ~[camel-core-2.11.4.jar:2.11.4]
        at org.apache.camel.processor.RouteInflightRepositoryProcessor.processNext(RouteInflightRepositoryProcessor.java:48) ~[camel-core-2.11.4.jar:2.11.4]
        at org.apache.camel.processor.DelegateAsyncProcessor.process(DelegateAsyncProcessor.java:90) ~[camel-core-2.11.4.jar:2.11.4]
        at org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHelper.java:73) ~[camel-core-2.11.4.jar:2.11.4]
        at org.apache.camel.processor.DelegateAsyncProcessor.processNext(DelegateAsyncProcessor.java:99) ~[camel-core-2.11.4.jar:2.11.4]
        at org.apache.camel.processor.DelegateAsyncProcessor.process(DelegateAsyncProcessor.java:90) ~[camel-core-2.11.4.jar:2.11.4]
        at org.apache.camel.management.InstrumentationProcessor.process(InstrumentationProcessor.java:72) ~[camel-core-2.11.4.jar:2.11.4]
        at org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHelper.java:73) ~[camel-core-2.11.4.jar:2.11.4]
        at org.apache.camel.processor.loadbalancer.QueueLoadBalancer.process(QueueLoadBalancer.java:44) ~[camel-core-2.11.4.jar:2.11.4]
        at org.apache.camel.util.AsyncProcessorHelper.process(AsyncProcessorHelper.java:99) ~[camel-core-2.11.4.jar:2.11.4]
        at org.apache.camel.processor.loadbalancer.QueueLoadBalancer.process(QueueLoadBalancer.java:71) ~[camel-core-2.11.4.jar:2.11.4]
        at org.apache.camel.component.quartz.QuartzEndpoint.onJobExecute(QuartzEndpoint.java:113) ~[camel-quartz-2.11.4.jar:2.11.4]
        at org.apache.camel.component.quartz.CamelJob.execute(CamelJob.java:61) ~[camel-quartz-2.11.4.jar:2.11.4]
        at org.quartz.core.JobRunShell.run(JobRunShell.java:223) ~[quartz-1.8.6.jar:na]
        at org.quartz.simpl.SimpleThreadPool$WorkerThread.run(SimpleThreadPool.java:549) ~[quartz-1.8.6.jar:na] **(a timer is triggered)**

InformationsquelleAutor abdel | 2015-01-13

0

Das Problem wird hier diskutiert large:

https://github.com/brettwooldridge/HikariCP/issues/34

Eingrenzen des Problems:
1. Versuchen, die Feder 4 mit Hibernate 4
2. Versuchen, eine andere Daten-Quelle zu sehen, wenn das problem weiterhin besteht.
vielen Dank für die Antwort. Ich war mit c3p0 datasource bevor hikari datasource und das Leck war auch passiert. Also ich vermute, dass entweder die Verbindung wird gelöscht, vorzeitig von postgres (unwahrscheinlich, da tcp_keep_alive die entsprechenden Einstellungen in postgres.conf-und linux-os nicht schlagen), oder spring/hibernate nicht loslassen Verbindung ordnungsgemäß. Ich bin mit neuesten Ruhezustand, als der aktuelle 4.3.8.Endgültig. Ich bin nicht sicher, ob ich das upgrade auf die Letzte Feder, aber Sie lassen weitere Untersuchungen
dies könnte auch ein Zusammenhang mit Frühlings-bug SPR-12280.

InformationsquelleAutor Cristian Sevescu
10

hier finden Sie einige Informationen, die ich denke, könnte nützlich sein für die Fehlersuche undichte Verbindung im Allgemeinen
- Ausschließen von Fehlalarmen. Zum Beispiel, wenn Sie eine Transaktion, die möglicherweise führen Sie für 5 Minuten (z.B., beim produzieren ein großer Bericht)
  und Sie gesetzt hatten, Ihre 'leakDetectionThreshold' - parameter (oder was auch immer das äquivalent für die von Ihnen gewählte Implementierung des Pools) , 4 Minuten, dann ist jede Transaktion, die länger als 4 Minuten wird berichtet, wie ein Leck, auch wenn es nicht eine echte Lecks (Transaktion konnte, würdevoll und angemessen lösen Sie alle verbindungen nach 5 Minuten).
- Wenn Sie mit einem connection pool aber selbst schnell feststellen, verbindungen gelegentlich dann überlegen Sie, wie Sie konfigurieren Ihren pool. In meinem Fall hatte ich konfiguriert den pool mit 'maximumPoolSize'=100. Hikari wird automatisch 'minimumIdle' config (minimale Anzahl an verbindungen im Leerlauf, HikariCP versucht zu halten in den pool), um die gleiche wie die von 'maximumPoolSize', also auf start-up-pool initialisiert wird mit allen max 100 verbindungen. Aber dies bedeutet, dass, wenn der 'maxLifetime' (die maximale Lebensdauer eines
  Verbindung im pool) feuert, dann werden alle verbindungen müssen erneuert werden gleichzeitig. Dies führt zu einer steilen vorübergehende Verringerung der verfügbaren verbindungen. In meinen logs, die ich gelegentlich zu sehen, folgenden Zeilen.
  
  HikariPool-0 (total=100, inUse=0, Anspruch=100, warten=0)
  
  HikariPool-0 (total=4, inUse=0, Anspruch=4, warten=0)
  
  HikariPool-0 (total=100, inUse=0, Anspruch=100, warten=0)
  
  in der zweiten Zeile, wo die verfügbaren verbindungen sank auf nur 4, wenn das 'maxLifetime' erreicht wurde und die verbindungen, die notwendige Erneuerung. Also bei der Konfiguration Ihres pool, tun Sie es in einer Weise, so dass die verbindungen zu unterschiedlichen Zeiten ablaufen. In meinem Fall habe ich einfach geändert "minimumIdle' auf 40, was bedeutet, dass bei steigender Last auf dem server, neue verbindungen werden inkrementell erworben (zu sehen, wenn Ihre pool-impl bietet das äquivalent von minToAcquire-Eigenschaft), und daher diese verbindungen haben unterschiedliche Verfallsdaten.
- Ihre Verbindung 'maxLifetime' müssen geringer sein als das, was Ihre Datenbank weist/erwartet für verbindungen, so dass Sie am Ende nicht mit verbindungen im pool, sind ungültig. UPDATE: einige Datenbanken möglicherweise zwingen unterbrechen die Verbindung nach einer gewissen Zeit. Zum Beispiel, postgres hat eine "connectionTimeout" und "socketTimeout" - Optionen. Also in Ihrer Anwendung connection pool, die Sie nicht wollen, zu halten die verbindungen für mehr als das db-erzwungen-connection-timeout, weil sonst werden Sie halten eine ungültig/bereits gelöschten Verbindung.
können Sie näher erläutern, "- Datenbank weist/erwartet für verbindungen"?
sorry für die späte Antwort. Grundsätzlich einige Datenbanken können Kraft-drop die Verbindung nach einiger Zeit. Zum Beispiel, postgres hat eine "connectionTimeout" und "socketTimeout" - Optionen. Also in Ihrer Anwendung connection pool, die Sie nicht wollen, zu halten die verbindungen für mehr als das db-erzwungen-connection-timeout, weil sonst werden Sie halten eine ungültig/bereits gelöschten Verbindung
vielen Dank - aktualisiert.

InformationsquelleAutor abdel

Schreibe einen Kommentar

Du musst angemeldet sein, um einen Kommentar abzugeben.