Hi,
we are trying to get our grails application to properly stop/undeploy (in
Tomcat) to avoid a 50MB permgen leak. It is probably a futile task... but there
is at least one issue caused by grails.
I have reconstructed the issue with grails 2.1 and a minimal grails app created
by 'grails create-app', 'grails war'. I deployed it to tomcat (7.0.29) and then
used the manager to undeploy it again.
The issue is caused by DataSourceGrailsPlugin.shutdownDatasource, which restarts
all org.apache.commons.dbcp.BasicDataSources to execute a shutdown on a hsql or
h2 database but fails to close it again leaving behind a running "Timer-1" thread.
DataSourceGrailsPlugin:
void shutdownDatasource(DataSource dataSource) {
Connection connection
try {
connection = dataSource.getConnection()
try {
def dbName = connection.metaData.databaseProductName
if (dbName == 'HSQL Database Engine' || dbName == 'H2') {
connection.createStatement().executeUpdate('SHUTDOWN')
}
} catch (e) {
// already closed, ignore
}
}
catch (e) {
log.error "Error shutting down datasource: $e.message", e
}
finally {
try { connection?.close() } catch (ignored) {}
}
}
The problem is that the data source were already shutdown by closing the spring
application context before shutdownDatasource gets called.
After deploying the app there is a "Timer-0" thread running created by the
BasicDataSource connection pool.
When I undeploy the app from tomcat the following thing happen in this order:
Spring cleans up the beans, calling the custom destroy methods (i.e. close on
the BasicDataSource) which stops the "Timer-0" thread.
GrailsDispatcherServlet.destroy ()
=> closes (Abstract)ApplicationContext@5806 (closed = true, active = false)
=> closes BasicDataSource (custom destroy method)
=> Timer-0 goes away
.. then GrailsContextLoader.closeWebApplicationContext () gets called which
requests the DataSource beans again, a new connection pool is created and a new
"Timer-1" gets started. closeWebApplicationContext () closes (multiple?)
contexts after the shutdown (the @5806 context too). But the context was already
closed, so closing it again will just return without doing anything. Keeping the
"Timer-1" thread running.
GrailsContextLoader.closeWebApplicationContext ()
=> ShutdownOperations.runOperations ()
=> DataSourceGrailsPlugin.onShutdown ()
=>
[hidden email](DataSource) (still closed = true, active =
false)
=> shutdownDataSource
=> dataSource.getConnection()
=> Timer-1 gets started
=> super.closeWebApplicationContext (@7682)
=>
[hidden email] ()
=> @5806.close ()
already closed, just returns, BasicDataSource is not closed again
From my perspective it looks like it is not a good idea to request a bean from
a context that was already shut down. I'm surprised that spring does not
complain...?
I am no expert on grails & spring but maybe replacing the close() method with
spring to include the hsql/h2 check would be a solution? That way it would be
possible to avoid the re-creation of the bean in the DataSourceGrailsPlugin
onShutdown hook.
--
Martin
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
Locked
