[ https://issues.apache.org/jira/browse/JCR-2927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13010029#comment-13010029 ]
Thomas Mueller commented on JCR-2927: ------------------------------------- I would rather not use "jdbc:derby:;shutdown=true" by default as it will close *all* Derby databases. What happens if multiple repositories are open, or if another application has a Derby database open at the same time? As far as I understand, this would also close those connections. One option is to use another database that doesn't have such problems. One example is the H2 database - http://h2database.com - disclaimer: I'm one of the H2 committers. I think HSQLDB should be fine as well (not sure). Another option is to call DriverManager.getConnection("jdbc:derby:;shutdown=true") yourself of course. > Shutdown of JCR with o.a.j.c.persistence.pool.DerbyPersistenceManager leaves > embedded Derby running > --------------------------------------------------------------------------------------------------- > > Key: JCR-2927 > URL: https://issues.apache.org/jira/browse/JCR-2927 > Project: Jackrabbit Content Repository > Issue Type: Bug > Components: jackrabbit-core > Affects Versions: 2.2.4 > Environment: JDK 1.6 > Reporter: Brian Topping > Labels: cleanup, leaks > > Using org.apache.jackrabbit.core.persistence.pool.DerbyPersistenceManager > will cause embedded Derby to be started properly but not completely shut > down. This is most easily seen looking at a thread dump after the > repositories have been shut down, there will be a thread created by Derby > called "derby.antiGC" still running. This is critical under a webserver like > Tomcat (all versions including 7) to not leak a lot of memory when a context > is reloaded. > The information I found to solve the issue is in > http://objectmix.com/apache/647660-derby-causes-permgen-leaks-tomcat.html#post2290996. > > At shutdown, org.apache.jackrabbit.core.util.db.DerbyConnectionHelper has > it's shutDown() method called, but that only shuts down individual > workspaces, for instance with a URL of "jdbc:derby:leakDB;shutdown=true". > The embedded database is still left running. > To shutdown the database service itself, "jdbc:derby:;shutdown=true" must be > used (note the missing database). > I'm not at all confident I understand the shutdown process well enough to > craft a patch that would be worth evaluation. On the other hand, I have > hacked together a skanky proof-of-concept that caches the DataSource for a > known workspace before repository shutdown, then closes the database itself > with the noted URL. It works, and in turn all the threads and memory with a > reference of the webapp classloader are released. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira