jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Thomas Mueller (JIRA)" <j...@apache.org>
Subject [jira] Commented: (JCR-1037) Memory leak causing performance problems
Date Thu, 09 Aug 2007 10:11:42 GMT

    [ https://issues.apache.org/jira/browse/JCR-1037?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12518678

Thomas Mueller commented on JCR-1037:


So far I can't reproduce this problem. With my test case, I only got 6 caches:
09.08.2007 11:52:30 *INFO * [main] CacheManager: resizeAll size=6 (CacheManager.java, line
(size=6 means 6 caches)

import org.apache.jackrabbit.core.TransientRepository;
import javax.jcr.*;
public class TestVersioning {
    public static void main(String[] args) throws Exception {
        Session session = new TransientRepository()
                .login(new SimpleCredentials("", new char[0]));
        Node node = session.getRootNode().addNode("test");
        for (int i = 0; i < 10000; i++) {
            node.setProperty("x", i);
            if(i % 10 == 0) {

Do you use multiple sessions, workspaces, clustering, or any other special configuration?


> Memory leak causing performance problems
> ----------------------------------------
>                 Key: JCR-1037
>                 URL: https://issues.apache.org/jira/browse/JCR-1037
>             Project: Jackrabbit
>          Issue Type: Bug
>          Components: Jackrabbit API
>    Affects Versions: 1.2.1, 1.2.2, 1.2.3, 1.3
>         Environment: Tomcat 6.0, XP Pro w/1Gb
>            Reporter: Antonio Carballo
>         Attachments: JCR-Trace.txt
> Folks,
> We have been running tests on JCR v1.3 and v1.2.1 for the past two weeks. The system
keeps running out of memory after X number of documents are added. Our initial test consisted
of about 50 documents and gradually increased to about 150 documents. The size of the documents
ranged from 1K to 9MB. We later changed the test to consist of files with less than 1K in
length with the same result. Increasing the heap size delays the error but the outcome is
always the same (Servlet runs out of heap memory.)
> Using JProbe we found a high number of references created by the caching sub-system (SessionItemStateManager.java,
SharedItemStateManager.java, LocalItemStateManager.java).  We changed the caching parameters
using CacheManager (min 64K - max 16MB). This change only delayed the error. Servlet eventually
runs out of heap memory.
> We are more than happy to share our findings (even source code and test data) with the
Jackrabbit team. Please let us know how you wish to proceed.
> Sincerely,
> Antonio Carballo

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message