[
https://issues.apache.org/jira/browse/JCR-1037?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12516399
]
Antonio Carballo commented on JCR-1037:
---------------------------------------
We were wondering if it was a way to turn off the caching-subsystem. We are
just getting nervous about JCR's ability to handle heavy loads with its current
caching algorithm. Please advice.
/Antonio
> 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
>
> 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.
