Fehler beim aufheben der Registrierung DataSource JMX-MBean Beim Herunterfahren eine Spring-Boot-Anwendung

Habe ich eine einfache Spring-Boot-Anwendung mit org.apache.Unterhaus.dbcp2.BasicDataSource als dataSource bean.

Datenquelle ausgesetzt ist als MBean automatisch von Spring boot.

Die Bohne Erklärung:

@Bean
public DataSource dataSource() {
    BasicDataSource dataSource = new BasicDataSource();
    dataSource.setUrl(dbUrl);
    dataSource.setDriverClassName(jdbcDriver);
    dataSource.setUsername(dbUserName);
    dataSource.setPassword(dbPassword);
    return dataSource;
}

Alles funktioniert einwandfrei . Aber ich sehe den Fehler beim Herunterfahren der Anwendung. Dieser Fehler tritt nur beim ausführen der ausführbaren jar. Bei der Verwendung von Gradle Frühjahr plugin (gradle bootRun), diese wird nicht angezeigt.

javax.management.InstanceNotFoundException: org.apache.commons.dbcp2:name=dataSource,type=BasicDataSource
    at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getMBean(DefaultMBeanServerInterceptor.java:1095)
    at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.exclusiveUnregisterMBean(DefaultMBeanServerInterceptor.java:427)
    at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.unregisterMBean(DefaultMBeanServerInterceptor.java:415)
    at com.sun.jmx.mbeanserver.JmxMBeanServer.unregisterMBean(JmxMBeanServer.java:546)
    at org.apache.commons.dbcp2.BasicDataSource.close(BasicDataSource.java:1822)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:483)
    at org.springframework.beans.factory.support.DisposableBeanAdapter.invokeCustomDestroyMethod(DisposableBeanAdapter.java:350)
    at org.springframework.beans.factory.support.DisposableBeanAdapter.destroy(DisposableBeanAdapter.java:273)
    at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.destroyBean(DefaultSingletonBeanRegistry.java:540)
    at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.destroySingleton(DefaultSingletonBeanRegistry.java:516)
    at org.springframework.beans.factory.support.DefaultListableBeanFactory.destroySingleton(DefaultListableBeanFactory.java:827)
    at org.springframework.beans.factory.support.DefaultSingletonBeanRegistry.destroySingletons(DefaultSingletonBeanRegistry.java:485)
    at org.springframework.context.support.AbstractApplicationContext.destroyBeans(AbstractApplicationContext.java:921)
    at org.springframework.context.support.AbstractApplicationContext.doClose(AbstractApplicationContext.java:895)
    at org.springframework.boot.context.embedded.EmbeddedWebApplicationContext.doClose(EmbeddedWebApplicationContext.java:152)
    at org.springframework.context.support.AbstractApplicationContext$1.run(AbstractApplicationContext.java:809)

Frage ich mich,
1. Wie funktioniert das bean ausgesetzt, als JMX MBean?
2. Wie man richtig die Registrierung dieser MBean?

Dies scheint nicht zu haben etwas zu tun mit Boot. Die datasource selbst versucht, aufheben der Registrierung von einem JMX-domain und scheitert. Wie über die Suche, dass Daten, die Art der Quelle der Dokumentation? Irgendeinen Grund, warum Sie nicht verwenden können, die Infrastruktur, die das boot bietet durch die Art und Weise?
Stolperte über dieses, wie ich erlebt haben das gleiche Problem. Es ist eigentlich kein Fehler - log meldet den Zustand als eine Warnung. Warum nicht verwenden Sie die Boot-Daten Quellen, ich würde vermuten, eine Vermutung, dass die OP will, um die Feinabstimmung der Verbindungs-pooling, und wenn Sie nicht in einem container (das wäre-pool für Sie), Sie nicht wirklich bekommen, eine zusammengefasste Verbindung von Boot (SimpleDriverDataSource nicht wirklich geben Ihnen zusammengefassten verbindungen). Ich würde gerne wissen, wie man dieses Problem beheben mit DBCP2, aber wenn es nur eine Warnung, die Auftritt, auf Herunterfahren, ich würde nicht zu viel sorgen darüber.
Das kommt von der Feder. Wie @Wird gesagt, dies ist nur eine Warnung. Die BasicDataSource versucht, aufheben der Registrierung, aber ist schon nicht eingetragenen durch die Feder (destroy() in MBeanExporter). Somit sollte es kein problem sein.

InformationsquelleAutor jlai | 2014-07-25

19

Frühling ist versucht zu schließen BasicDataSource zweimal:
1. BasicDataSource schließen sich automatisch, wenn die Anwendung schließen
2. Frühling zerstören, verwenden Sie die Standard-Methode zum schließen der DataSource-aber es ist bereits geschlossen
Um dies zu vermeiden, verwenden Sie:
```
@Bean(destroyMethod = "")
public DataSource dataSource() 
```
In Ihre Java-Konfiguration

das ist mein problem gelöst , nicht mehr stack-trace beim Herunterfahren des Servers
Funktioniert perfekt, das Problem gelöst für mich
Ich danke Ihnen sehr 🙂

InformationsquelleAutor Marcon
1

Ich lief in das gleiche problem. Hinzufügen eines MBean-server und registrieren die datasource kann nicht fix it entweder.

http://docs.spring.io/spring/docs/current/spring-framework-reference/html/jmx.html

Mein Fazit ist, dass DBCP2 die BasicDataSource hat einen Fehler bei der Registrierung selbst aus dem MBean-server.

Ich behoben, die mir durch den Wechsel zu mchange ist c3p0:
http://www.mchange.com/projects/c3p0/

InformationsquelleAutor user832462
1

BasicDataSource extends BasicDataSourceMXBean, so ist es auto registriert mit der JMX-MBean-server als [org.apache.commons.dbcp2:name=dataSource,type=BasicDataSource]. Wenn springboot Abschaltungen, MBeanExporter hebt die Registrierung der MBean, dann springboot versucht zu zerstören BasicDataSource, und fordert BasicDataSource Methode close() ist, hebt die Registrierung der MBean wieder (BasicDataSource fängt die JMException, und drucken Sie diese Warnung). Es ist nur eine Warnung. Wenn Sie nicht wollen, es zu drucken, können Sie deaktivieren Sie die JMX-in springboot.
```
application.yml
spring:
jmx:
enabled: false
```
InformationsquelleAutor helinxiang

Ich hatte das gleiche Problem.
c3p0 funktioniert sehr gut.

wenn mit spring framework - pom.xml

<!-- https://mvnrepository.com/artifact/com.mchange/c3p0 -->
<dependency>
   <groupId>com.mchange</groupId>
   <artifactId>c3p0</artifactId>
   <version>0.9.5.2</version>
</dependency>

zunächst

DataSource ds_unpooled = DataSources.unpooledDataSource(persistenceUrl,
            persistenceUsername,
            persistencePassword);
return DataSources.pooledDataSource(ds_unpooled);

aber es könnte nicht mit der Last, die ich ausführen und schaltete den folgenden

ComboPooledDataSource cpds = new ComboPooledDataSource();
    cpds.setDriverClass( persistenceDriver ); //loads the jdbc driver
    cpds.setJdbcUrl( persistenceUrl );
    cpds.setUser(persistenceUsername);
    cpds.setPassword(persistencePassword);
    cpds.setMinPoolSize(5);
    cpds.setMaxPoolSize(50);
    cpds.setUnreturnedConnectionTimeout(1800);
    cpds.setMaxStatements(50);
    cpds.setMaxIdleTime(21600);
    cpds.setIdleConnectionTestPeriod(10800);
return cpds;

diese Werte sind aus anderen posts, die ich gesammelt haben online.

meiner Erfahrung für meine konkrete Aufgabe ausführen c3p0 führt schneller als dbcp2 v:2.1.1 unter der gleichen Umgebung.

hoffe, dies hilft ein wenig.
prost!

InformationsquelleAutor simple

Schreibe einen Kommentar

Du musst angemeldet sein, um einen Kommentar abzugeben.