jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Neil Lott <neilmatthewl...@yahoo.com>
Subject Re: Oracle 10g and Jackrabbit
Date Sat, 27 Feb 2010 05:28:51 GMT
So I downloaded the branch and changed the bundleCacheSize to 50MB as I couldn't find a way
to configure this value via xml.

Its now working and I got past my 2500 mark with no problem.

I'm curious why the choice was made to use this cache and why wouldn't we be allowed to disable
it?

Thanks,

Neil


On Feb 26, 2010, at 9:49 PM, Neil Lott wrote:

> It still doesn't make sense as it looks like the BundleCache is the gating factor.
> 
> 2010-02-26 21:22:08,534 DEBUG [main] (ItemManager.cacheItem:904) - caching item bb67f961-70b9-4014-978c-e557e113c1d8/{}title
> 2010-02-26 21:22:08,538  INFO [main] (BundleCache.get:106) - num=1972 mem=8111k max=8192k
avg=4212 hits=2007848 miss=2152
> 2010-02-26 21:22:08,540 DEBUG [main] (AbstractBundlePersistenceManager.putBundle:684)
- stored bundle bb67f961-70b9-4014-978c-e557e113c1d8
> 
> 2010-02-26 21:22:09,245 DEBUG [main] (ItemManager.cacheItem:904) - caching item 0c5e9c05-1ee9-414f-a092-a9ce918843be/{}title
> 2010-02-26 21:22:09,282  INFO [main] (BundleCache.get:106) - num=1972 mem=8113k max=8192k
avg=4212 hits=2017848 miss=2152
> 2010-02-26 21:22:09,391 DEBUG [main] (AbstractBundlePersistenceManager.putBundle:684)
- stored bundle 0c5e9c05-1ee9-414f-a092-a9ce918843be
> 
> 2010-02-26 21:22:23,592 DEBUG [main] (ItemManager.cacheItem:904) - caching item b3998a96-e37d-4124-8e02-7963d624ad9e/{http://www.jcp.org/jcr/1.0}primaryType
> 2010-02-26 21:22:25,534  INFO [main] (BundleCache.get:106) - num=1991 mem=8189k max=8192k
avg=4212 hits=2018497 miss=11503
> 2010-02-26 21:22:26,941 DEBUG [main] (AbstractBundlePersistenceManager.putBundle:684)
- stored bundle 0992c129-2ffa-4c04-89d4-ab9a5de4694c
> 
> 2010-02-26 21:22:33,966 DEBUG [main] (ItemManager.cacheItem:904) - caching item b84d2a5b-9e67-4817-8494-8c7daf4a322b/{}title
> 2010-02-26 21:22:37,313 DEBUG [main] (AbstractBundlePersistenceManager.putBundle:684)
- stored bundle 7f103008-bdf9-4d47-861b-c14216776537
> 
> 2010-02-26 21:22:41,198 DEBUG [main] (ItemManager.cacheItem:904) - caching item 6229608f-7e07-422c-9ccf-57befc6da0d6/{}title
> 2010-02-26 21:22:42,779  INFO [main] (BundleCache.get:106) - num=1991 mem=8191k max=8192k
avg=4212 hits=2018497 miss=21503
> 2010-02-26 21:22:44,383 DEBUG [Timer-1] (MultiIndex.checkFlush:1281) - Flushing index
after being idle for 3241 ms.
> 
> So why is it necessary to have this BundleCache?  I tried configuring it and it doesn't
pick up my changes?  Are there alternatives?
> 
> Thanks,
> 
> Neil
> 
> On Feb 26, 2010, at 5:56 PM, Rakesh Vidyadharan wrote:
> 
>> 
>> On 26 Feb 2010, at 18:52, Neil Lott wrote:
>> 
>>> Thanks Justin,
>>> 
>>> Even though I can add more that 2450 nodes each time I add a node its really
slow after that number.  What would you suggest for troubleshooting this further?
>>> 
>>> Neil
>> 
>> It is going to get slower as the number of child nodes grow.  Your only option with
JR is to partition your tree.  I had run into this issue as well a while ago (although I had
only around 10K under a parent node), and took the usual recommendation of partitioning the
tree.  Performance increased drastically after that.
>> 
>> Rakesh
> 


Mime
View raw message