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
>
>
>
