jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "MARTINEZ Antonio" <Antonio.Marti...@alcatel-lucent.com>
Subject RE: Read locks while Saving (using FineGrainedISMLocking)
Date Thu, 18 Sep 2008 23:26:15 GMT
Hello Marcel,

Indeed that was the problem. It works now (I also set
respectDocumentOrder to false)

Thank-you,
Antonio
 

-----Original Message-----
From: Marcel Reutegger [mailto:marcel.reutegger@gmx.net] 
Sent: Wednesday, September 17, 2008 4:26 AM
To: users@jackrabbit.apache.org
Subject: Re: Read locks while Saving (using FineGrainedISMLocking)

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$ReaderL
> oc
> k)
>         at java.lang.Object.wait(Object.java:485)
>         at
> EDU.oswego.cs.dl.util.concurrent.WriterPreferenceReadWriteLock$ReaderL
> oc
> k.acquire(WriterPreferenceReadWriteLock.java:163)
>         - locked <0x7c88c3d0> (a
> EDU.oswego.cs.dl.util.concurrent.WriterPreferenceReadWriteLock$ReaderL
> oc
> 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(Def
> au
> ltISMLocking.java:65)
>         at
> org.apache.jackrabbit.core.state.SharedItemStateManager.acquireReadLoc
> k(
> SharedItemStateManager.java:1454)
>         at
> org.apache.jackrabbit.core.state.SharedItemStateManager.hasItemState(S
> ha
> redItemStateManager.java:270)
>         at
> org.apache.jackrabbit.core.state.LocalItemStateManager.hasItemState(Lo
> ca
> lItemStateManager.java:178)
>         at
> org.apache.jackrabbit.core.state.XAItemStateManager.hasItemState(XAIte
> mS
> tateManager.java:254)
>         at
> org.apache.jackrabbit.core.state.SessionItemStateManager.getItemState(
> Se
> ssionItemStateManager.java:185)
>         at
> org.apache.jackrabbit.core.HierarchyManagerImpl.getItemState(Hierarchy
> Ma
> nagerImpl.java:188)
>         at
> org.apache.jackrabbit.core.HierarchyManagerImpl.buildPath(HierarchyMan
> ag
> erImpl.java:325)
>         at
> org.apache.jackrabbit.core.CachingHierarchyManager.buildPath(CachingHi
> er
> archyManager.java:162)
>         at
> org.apache.jackrabbit.core.HierarchyManagerImpl.getPath(HierarchyManag
> er
> Impl.java:402)
>         at
> org.apache.jackrabbit.core.CachingHierarchyManager.getPath(CachingHier
> ar
> chyManager.java:272)
>         at
> org.apache.jackrabbit.core.ItemImpl.getPrimaryPath(ItemImpl.java:296)
>         at
> org.apache.jackrabbit.core.query.lucene.DocOrderNodeIteratorImpl$1.com
> pa
> 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.initO
> rd
> eredIterator(DocOrderNodeIteratorImpl.java:172)
>         at
> org.apache.jackrabbit.core.query.lucene.DocOrderNodeIteratorImpl.hasNe
> xt
> (DocOrderNodeIteratorImpl.java:131)
>         at
> com.fonter.axs.app.idm.InventoryDiscoveryServiceImpl$4$1.execute(Inven
> to
> ryDiscoveryServiceImpl.java:502)
>         at
> com.fonter.axs.app.idm.InventoryDiscoveryServiceImpl.execute(Inventory
> Di
> scoveryServiceImpl.java:405)
>         at
> com.fonter.axs.app.idm.InventoryDiscoveryServiceImpl.access$100(Invent
> or
> yDiscoveryServiceImpl.java:89)
>         at
> com.fonter.axs.app.idm.InventoryDiscoveryServiceImpl$4.doInTransaction
> (I
> nventoryDiscoveryServiceImpl.java:481)
>         at
> org.springframework.transaction.support.TransactionTemplate.execute(Tr
> an
> sactionTemplate.java:128)
>         at
> com.fonter.axs.app.idm.InventoryDiscoveryServiceImpl.queryData(Invento
> ry
> 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