You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by "Brian Topping (JIRA)" <ji...@apache.org> on 2011/03/23 08:04:05 UTC
[jira] [Created] (JCR-2927) Shutdown of JCR with
o.a.j.c.persistence.pool.DerbyPersistenceManager leaves embedded Derby
running
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
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
[jira] [Commented] (JCR-2927) Shutdown of JCR with
o.a.j.c.persistence.pool.DerbyPersistenceManager leaves embedded Derby
running
Posted by "Brian Topping (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/JCR-2927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13021044#comment-13021044 ]
Brian Topping commented on JCR-2927:
------------------------------------
Hi Thomas, thanks for the response, the notification on this slipped through my inbox undetected.
I'm okay with different databases, I considered later that it might be the right way to go. I personally use PostgreSQL, but stuck with an in-JVM version of Derby here in an attempt to reduce serialization overhead. Is there any commentary on performance of different databases with Jackrabbit on forums?
I assume Day's TarFS is not available for Jackrabbit?
> 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
[jira] [Commented] (JCR-2927) Shutdown of JCR with
o.a.j.c.persistence.pool.DerbyPersistenceManager leaves embedded Derby
running
Posted by "Thomas Mueller (JIRA)" <ji...@apache.org>.
[ 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