[ http://issues.apache.org/jira/browse/JCR-619?page=comments#action_12454399 ] Xiaohua Lu commented on JCR-619: --------------------------------
I managed to reproduce the deadlock with 2 concurrent query. both query are select all category nodes. the test data is the same as before. The definition of data as as following : <nt = 'http://www.jcp.org/jcr/nt/1.0'> <mix = 'http://www.jcp.org/jcr/mix/1.0'> <mvn = 'http://maven.net/jcr/mock'> <mvnnt = 'http://maven.net/jcr/nt/mock'> [mvnnt:categoryHierarchyNode] > nt:base [mvnnt:category] > mvnnt:categoryHierarchyNode, mix:referenceable - mvn:description (string) - mvn:content (reference) multiple + * (mvnnt:categoryHierarchyNode) --- note : the content field will point to file node and it is not used in this test. the query both threads are trying to perform is //element (*, mvnnt:category) -- note : The query returned very quickly and the deadlock happened when both threads tried to iterate through the NoteIterator to make sure the returned result are of type mvnnt:category. The jstack output is as followings : Thread [EMAIL PROTECTED]: (state = BLOCKED) - org.apache.jackrabbit.core.state.CacheManager.cacheAccessed() @bci=18, line=77 (Interpreted frame) - org.apache.jackrabbit.core.state.MLRUItemStateCache.touch() @bci=34, line=222 (Compiled frame) - org.apache.jackrabbit.core.state.MLRUItemStateCache.retrieve(org.apache.jackrabbit.core.ItemId) @bci=8, line=97 (Compiled frame) - org.apache.jackrabbit.core.state.ItemStateReferenceCache.retrieve(org.apache.jackrabbit.core.ItemId) @bci=5, line=99 (Compiled frame) - org.apache.jackrabbit.core.state.XAItemStateManager.getItemState(org.apache.jackrabbit.core.ItemId) @bci=54, line=233 (Compiled frame) - org.apache.jackrabbit.core.state.SessionItemStateManager.getItemState(org.apache.jackrabbit.core.ItemId) @bci=56, line=165 (Compiled frame) - org.apache.jackrabbit.core.ItemManager.createItemInstance(org.apache.jackrabbit.core.ItemId) @bci=5, line=462 (Compiled frame) - org.apache.jackrabbit.core.ItemManager.getItem(org.apache.jackrabbit.core.ItemId) @bci=63, line=320 (Compiled frame) - org.apache.jackrabbit.core.query.lucene.NodeIteratorImpl.fetchNext() @bci=46, line=194 (Compiled frame) - org.apache.jackrabbit.core.query.lucene.NodeIteratorImpl.nextNodeImpl() @bci=21, line=103 (Compiled frame) - net.maven.cr.test.PerformanceQueryTest$ListCategoriesQueryTestContext.verify(javax.jcr.NodeIterator) @bci=25 (Interpreted frame) - net.maven.cr.test.PerformanceQueryTest.timingQuery(net.maven.cr.test.PerformanceQueryTest$QueryTestContext) @bci=34 (Interpreted frame) - net.maven.cr.test.PerformanceQueryTest.access$100(net.maven.cr.test.PerformanceQueryTest, net.maven.cr.test.PerformanceQueryTest$QueryTestContext) @bci=2 (Interpreted frame) - net.maven.cr.test.PerformanceQueryTest$TimedQueryTest.run() @bci=32 (Interpreted frame) Thread [EMAIL PROTECTED]: (state = BLOCKED) - org.apache.jackrabbit.core.state.MLRUItemStateCache.getMemoryUsed() @bci=6, line=245 (Compiled frame; information may be imprecise) - org.apache.jackrabbit.core.state.CacheManager$CacheInfo.<init>(org.apache.jackrabbit.core.state.Cache) @bci=21, line=212 (Interpreted frame) - org.apache.jackrabbit.core.state.CacheManager.resizeAll() @bci=136, line=107 (Compiled frame) - org.apache.jackrabbit.core.state.CacheManager.cacheAccessed() @bci=40, line=81 (Interpreted frame) - org.apache.jackrabbit.core.state.MLRUItemStateCache.touch() @bci=34, line=222 (Compiled frame) - org.apache.jackrabbit.core.state.MLRUItemStateCache.cache(org.apache.jackrabbit.core.state.ItemState) @bci=8, line=129 (Compiled frame) - org.apache.jackrabbit.core.state.ItemStateReferenceCache.cache(org.apache.jackrabbit.core.state.ItemState) @bci=48, line=114 (Compiled frame) - org.apache.jackrabbit.core.state.LocalItemStateManager.getNodeState(org.apache.jackrabbit.core.NodeId) @bci=31, line=99 (Compiled frame) - org.apache.jackrabbit.core.state.LocalItemStateManager.getItemState(org.apache.jackrabbit.core.ItemId) @bci=47, line=150 (Compiled frame) - org.apache.jackrabbit.core.state.XAItemStateManager.getItemState(org.apache.jackrabbit.core.ItemId) @bci=54, line=233 (Compiled frame) - org.apache.jackrabbit.core.state.SessionItemStateManager.getItemState(org.apache.jackrabbit.core.ItemId) @bci=56, line=165 (Compiled frame) - org.apache.jackrabbit.core.ItemManager.createItemInstance(org.apache.jackrabbit.core.ItemId) @bci=5, line=462 (Compiled frame) - org.apache.jackrabbit.core.ItemManager.getItem(org.apache.jackrabbit.core.ItemId) @bci=63, line=320 (Compiled frame) - org.apache.jackrabbit.core.query.lucene.NodeIteratorImpl.fetchNext() @bci=46, line=194 (Compiled frame) - org.apache.jackrabbit.core.query.lucene.NodeIteratorImpl.nextNodeImpl() @bci=21, line=103 (Compiled frame) - net.maven.cr.test.PerformanceQueryTest$ListCategoriesQueryTestContext.verify(javax.jcr.NodeIterator) @bci=25 (Interpreted frame) - net.maven.cr.test.PerformanceQueryTest.timingQuery(net.maven.cr.test.PerformanceQueryTest$QueryTestContext) @bci=34 (Interpreted frame) - net.maven.cr.test.PerformanceQueryTest.access$100(net.maven.cr.test.PerformanceQueryTest, net.maven.cr.test.PerformanceQueryTest$QueryTestContext) @bci=2 (Interpreted frame) - net.maven.cr.test.PerformanceQueryTest$TimedQueryTest.run() @bci=32 (Interpreted frame) > 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
