jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcel Reutegger <marcel.reuteg...@gmx.net>
Subject Re: Read locks while Saving (using FineGrainedISMLocking)
Date Wed, 17 Sep 2008 11:26:25 GMT
Hi,

it seems that you did not change the workspace.xml. the workspace section in
repository.xml only acts as a template for newly created workspaces. if you have
existing workspaces you need to change the workspace.xml files as well.

furthermore the thread dump shows that the query result is returned in document
order (DocOrderNodeIteratorImpl), which comes with a performance penalty. is
this intended? if you don't need document order on the result set you can either
turn it off completely by configuration (add <param name="respectDocumentOrder"
value="false"/> to the SearchIndex element) or by specifying an order by clause
such as 'order by @jcr:score'.

regards
 marcel


MARTINEZ Antonio wrote:
> Hi Marcel,
> 
> This is the thread dump.
> Looks like the read is locked on WriterPreferenceReadWriteLock.
> Is there a way to avoid that read waits on the write.
> 
> Thanks,
> Antonio
> 
> "RMI TCP Connection(301)-143.209.39.176" daemon prio=3 tid=0x02d06800
> nid=0x4316 in Object.wait() [0x49c7d000..0x49c7f8f0]
>    java.lang.Thread.State: WAITING (on object monitor)
>         at java.lang.Object.wait(Native Method)
>         - waiting on <0x7c88c3d0> (a
> EDU.oswego.cs.dl.util.concurrent.WriterPreferenceReadWriteLock$ReaderLoc
> k)
>         at java.lang.Object.wait(Object.java:485)
>         at
> EDU.oswego.cs.dl.util.concurrent.WriterPreferenceReadWriteLock$ReaderLoc
> k.acquire(WriterPreferenceReadWriteLock.java:163)
>         - locked <0x7c88c3d0> (a
> EDU.oswego.cs.dl.util.concurrent.WriterPreferenceReadWriteLock$ReaderLoc
> k)
>         at
> org.apache.jackrabbit.core.state.DefaultISMLocking$ReadLockImpl.<init>(D
> efaultISMLocking.java:103)
>         at
> org.apache.jackrabbit.core.state.DefaultISMLocking$ReadLockImpl.<init>(D
> efaultISMLocking.java:97)
>         at
> org.apache.jackrabbit.core.state.DefaultISMLocking.acquireReadLock(Defau
> ltISMLocking.java:65)
>         at
> org.apache.jackrabbit.core.state.SharedItemStateManager.acquireReadLock(
> SharedItemStateManager.java:1454)
>         at
> org.apache.jackrabbit.core.state.SharedItemStateManager.hasItemState(Sha
> redItemStateManager.java:270)
>         at
> org.apache.jackrabbit.core.state.LocalItemStateManager.hasItemState(Loca
> lItemStateManager.java:178)
>         at
> org.apache.jackrabbit.core.state.XAItemStateManager.hasItemState(XAItemS
> tateManager.java:254)
>         at
> org.apache.jackrabbit.core.state.SessionItemStateManager.getItemState(Se
> ssionItemStateManager.java:185)
>         at
> org.apache.jackrabbit.core.HierarchyManagerImpl.getItemState(HierarchyMa
> nagerImpl.java:188)
>         at
> org.apache.jackrabbit.core.HierarchyManagerImpl.buildPath(HierarchyManag
> erImpl.java:325)
>         at
> org.apache.jackrabbit.core.CachingHierarchyManager.buildPath(CachingHier
> archyManager.java:162)
>         at
> org.apache.jackrabbit.core.HierarchyManagerImpl.getPath(HierarchyManager
> Impl.java:402)
>         at
> org.apache.jackrabbit.core.CachingHierarchyManager.getPath(CachingHierar
> chyManager.java:272)
>         at
> org.apache.jackrabbit.core.ItemImpl.getPrimaryPath(ItemImpl.java:296)
>         at
> org.apache.jackrabbit.core.query.lucene.DocOrderNodeIteratorImpl$1.compa
> re(DocOrderNodeIteratorImpl.java:196)
>         at java.util.Arrays.mergeSort(Arrays.java:1270)
>         at java.util.Arrays.mergeSort(Arrays.java:1281)
>         at java.util.Arrays.mergeSort(Arrays.java:1281)
>         at java.util.Arrays.mergeSort(Arrays.java:1282)
>         at java.util.Arrays.mergeSort(Arrays.java:1281)
>         at java.util.Arrays.mergeSort(Arrays.java:1282)
>         at java.util.Arrays.mergeSort(Arrays.java:1281)
>         at java.util.Arrays.mergeSort(Arrays.java:1282)
>         at java.util.Arrays.mergeSort(Arrays.java:1282)
>         at java.util.Arrays.sort(Arrays.java:1210)
>         at
> org.apache.jackrabbit.core.query.lucene.DocOrderNodeIteratorImpl.initOrd
> eredIterator(DocOrderNodeIteratorImpl.java:172)
>         at
> org.apache.jackrabbit.core.query.lucene.DocOrderNodeIteratorImpl.hasNext
> (DocOrderNodeIteratorImpl.java:131)
>         at
> com.fonter.axs.app.idm.InventoryDiscoveryServiceImpl$4$1.execute(Invento
> ryDiscoveryServiceImpl.java:502)
>         at
> com.fonter.axs.app.idm.InventoryDiscoveryServiceImpl.execute(InventoryDi
> scoveryServiceImpl.java:405)
>         at
> com.fonter.axs.app.idm.InventoryDiscoveryServiceImpl.access$100(Inventor
> yDiscoveryServiceImpl.java:89)
>         at
> com.fonter.axs.app.idm.InventoryDiscoveryServiceImpl$4.doInTransaction(I
> nventoryDiscoveryServiceImpl.java:481)
>         at
> org.springframework.transaction.support.TransactionTemplate.execute(Tran
> sactionTemplate.java:128)
>         at
> com.fonter.axs.app.idm.InventoryDiscoveryServiceImpl.queryData(Inventory
> DiscoveryServiceImpl.java:478)
> 
> 
> 
>>> Hi,
> 
>>> IIUC this is not an issue with the ISMLocking implementation but 
>>> rather how the
> query handler implementation works. can you provide a thread dump that
> shows the waiting thread? that would clarify what exactly causes the
> locking.
> 
> regards
>  marcel
> 
>> MARTINEZ Antonio wrote:
>>> Hello,
>>>
>>> I'm using JackRabbit 1.4.4.
>>>
>>> We are facing the issue of a query taking too long while saving a big
> 
>>> Tree.
>>>
>>> I read about JCR-314 (Fine grained locking in SharedItemStateManager)
> 
>>> and modified repository.xml adding
>>>    <ISMLocking
>>> class="org.apache.jackrabbit.core.state.FineGrainedISMLocking">
>>>    </ISMLocking>
>>> Still the query locks if I do it while saving the tree.
>>>
>>>
>>> This is the structure of our repository (the tree is actually more 
>>> than 10 levels deep)
>>>
>>> rootNode ---- nodeLevel_1 (p1=a, p2=x, ..) --- nodeLevel_2 (p1=t,
>>> p2,..)
>>>  
>>>                                            --- nodeLevel_2 (p1=u,
>>> p2,..)
>>>
>>>                                            --- nodeLevel_2 (p1=v,
>>> p2,..)
>>>
>>>                                            --- nodeLevel_2 (p1=w, p2,
>>>
>>>
>>>               nodeLevel_1 (p1=b, p2=y, ..) --- nodeLevel_2 (p1=m,
>>> p2,..)
>>>
>>>                                            --- nodeLevel_2 (p1=n,
>>> p2,..)
>>>
>>>                                            --- nodeLevel_2 (p1=o,
>>> p2,..)
>>>
>>>                                            --- nodeLevel_2 (p1=p,
>>> p2,..)
>>>
>>>
>>>
>>> I'd like to know how FineGrainedISMLocking actually works and if 
>>> there is something more we can do to avoid the query from waiting on
> a lock.
>>> - Let's assume I write the tree under "nodeLevel_1 (p1=a, p2=x, ..)".
> 
>>>   Should the query //rootNode//[EMAIL PROTECTED]'b']  lock for the 
>>> write to finish ? It actually locks now
>>>   
>>>   Maybe read locks because needs to evaluate nodeLevel_1 (p1=a, p2=x,
>>> ..) in case p1 actually also equals 'b'?
>>>   In our case p1 is has a UNIQUE value for each nodeLevel_1. Can we 
>>> somehow let JR know that so it does not wait?
>>>
>>>   Is there a way for read to actually go ahead best effort returning 
>>> only those matches not locked by write?
>>>
>>>
>>> I really appreciate any help, this is a show stopper issue for us.
>> Thanks,
>> Antonio
>>
>>
>>
> 
> 


Mime
View raw message