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:[EMAIL PROTECTED] Sent: Wednesday, September 17, 2008 4:26 AM To: [email protected] 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 >> >> >> > >
