[ http://issues.apache.org/jira/browse/JCR-619?page=all ]
Xiaohua Lu updated JCR-619:
---------------------------
Attachment: stack.txt
I have been running a concurrent test on Nov. 28th code base. A deadlock has
been encouterred. The setup of the test is :
1. 6000 file nodes flat under root node
2. 900 category nodes, three level deep under root node
3. 50 concurrent thread, each one perform one of the four queries :
3.1 select all file nodes
3.2 select all category nodes
3.3 select file nodes by file property
3.4 select category nodes by category property
The tests only involved query, no add/delete/update are included. From the
jstack.txt attached, you can see a few threads are blocking each other, it
looks similar to what Tom reported a few weeks ago.
> CacheManager (Memory Management in Jackrabbit)
> ----------------------------------------------
>
> Key: JCR-619
> URL: http://issues.apache.org/jira/browse/JCR-619
> Project: Jackrabbit
> Issue Type: New Feature
> Components: core
> Affects Versions: 1.1
> Reporter: Thomas Mueller
> Assigned To: Stefan Guggisberg
> Fix For: 1.2
>
> Attachments: cacheManager.txt, cacheManager2.txt, cacheManager5.txt,
> cacheManager6.txt, stack.txt
>
>
> Jackrabbit can run out of memory because the the combined size of the various
> caches is not managed. The biggest problem (for me) is the combined size of
> the o.a.j.core.state.MLRUItemStateCache caches. Each session seems to create
> a few (?) of those caches, and each one is limited to 4 MB by default.
> I have implemented a dynamic (cache-) memory management service that
> distributes a fixed amount of memory dynamically to all those caches.
> Here is the patch
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
