Excepción de fugas de memoria

Question

¿Puede alguien ayudarme con esta excepción:

Jul 23, 2012 11:00:57 AM org.apache.catalina.loader.WebappClassLoader loadClass
INFO: Illegal access: this web application instance has been stopped already.  Could not load com.mchange.v2.sql.SqlUtils.  The eventual following stack trace is caused by an error thrown for debugging purposes as well as to attempt to terminate the thread which caused the illegal access, and has no functional impact.
java.lang.IllegalStateException
    at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1597)
    at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1556)
    at com.mchange.v2.c3p0.impl.C3P0PooledConnectionPool.checkoutPooledConnection(C3P0PooledConnectionPool.java:531)
    at com.mchange.v2.c3p0.impl.AbstractPoolBackedDataSource.getConnection(AbstractPoolBackedDataSource.java:128)
    at org.hibernate.connection.C3P0ConnectionProvider.getConnection(C3P0ConnectionProvider.java:78)
    at org.hibernate.jdbc.ConnectionManager.openConnection(ConnectionManager.java:446)
    at org.hibernate.jdbc.ConnectionManager.getConnection(ConnectionManager.java:167)
    at org.hibernate.jdbc.JDBCContext.connection(JDBCContext.java:142)
    at org.hibernate.transaction.JDBCTransaction.begin(JDBCTransaction.java:85)
    at net.customware.gwt.dispatch.server.AbstractDispatch.doExecute(AbstractDispatch.java:81)
    at net.customware.gwt.dispatch.server.AbstractDispatch.execute(AbstractDispatch.java:68)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:601)
    at com.google.gwt.user.server.rpc.RPC.invokeAndEncodeResponse(RPC.java:569)
    at com.google.gwt.user.server.rpc.RemoteServiceServlet.processCall(RemoteServiceServlet.java:208)
    at com.google.gwt.user.server.rpc.RemoteServiceServlet.processPost(RemoteServiceServlet.java:248)
    at com.google.gwt.user.server.rpc.AbstractRemoteServiceServlet.doPost(AbstractRemoteServiceServlet.java:62)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:641)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
    at com.google.inject.servlet.ServletDefinition.doService(ServletDefinition.java:216)
    at com.google.inject.servlet.ServletDefinition.service(ServletDefinition.java:141)
    at com.google.inject.servlet.ManagedServletPipeline.service(ManagedServletPipeline.java:93)
    at com.google.inject.servlet.FilterChainInvocation.doFilter(FilterChainInvocation.java:63)
    at com.google.inject.servlet.ManagedFilterPipeline.dispatch(ManagedFilterPipeline.java:122)
    at com.google.inject.servlet.GuiceFilter.doFilter(GuiceFilter.java:110)
    at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
    at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
    at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:225)
    at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:169)
    at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472)
    at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:168)
    at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:98)
    at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:927)
    at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
    at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407)
    at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:999)
    at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:565)
    at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:309)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
    at java.lang.Thread.run(Thread.java:722)

y también proporciona la posible solución para ello ..?

gracias de antemano ...

Answer 1

El problema básico es que Tomcat crea un nuevo cargador de clases para cada WebApp y deshabilita al Classloader cuando restablece la aplicación, por ejemplo. por hot despliegue una nueva versión. C3P0 crea hilos de ayuda. Si C3P0 se ha cargado dentro de la cargadora de clase de la aplicación web y luego se restablece la aplicación, las subproces de C3P0 todavía pueden estar en vivo y mantener referencias a objetos cargados del AHORA Class Classloader, lo que lleva al tipo de error que vea cuando una nueva clase debe ser cargado.

Las interacciones entre componentes multithreaded y el esquema de carga de clases "caliente" de Tomcat pueden ser desafiantes. Algunas sugerencias:

1) Si su aplicación web construye su propio DataSource C3P0 (por ejemplo, en un Listedor de contexto), asegúrese de que el DataSource también esté cerca () ED cuando la aplicación se apague (en el mismo contextListener)

2) Intente tener C3P0 y sus clases de controladores JDBC cargados en algo que no sea el cargador de clases específico de la aplicación web. Ponga el archivo JAR C3P0, el archivo JAR CAMBE-Commons-Java, y su archivo JDBC Driver Jar, donde el Classloader común, sistema o bootstrap lo encontrará. Asegúrese de que estos archivos salgan a cabo el directorio de Lib de su WebApp, porque el cargador de la aplicación web se intenta primero. Consulte http://tomcat.apache.org/tomcat-6.0- doc / class-loader-howto.html para más.

¡Espero que esto ayude!