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 Wed, 17 Sep 2008 02:18:27 GMT
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