Hello Marcel, the monitor contention issue could be fixed by using EDU.oswego.cs.dl.util.concurrent.ReadWriteLock as has been done in other places in the JackRabbit code. I have one issue with the Sync.acquire() method that throws an InterruptedException.
This exception is treaded differently in the JackRabbit code. Sometimes it is ignored, sometimes wrapped in a checked or unchecked exception. If this issue is solved, I can mail you the new version of this class for reviewing. Next week I'm out of the office, but after that I can continue my work on this issue. Arthur > -----Original Message----- > From: Marcel Reutegger [mailto:[EMAIL PROTECTED] > Sent: Thursday, October 19, 2006 5:11 PM > To: [email protected] > Subject: Re: JackRabbit performance and scalability > > Hi Arthur, > > thanks a lot for investigating the performance of jackrabbit > in such detail. > > you seem to have quite a good understanding of the internals > of jackrabbit. Can I encourage you to propose patches for the > hot spots you identified? > > we will be happy to review them and incorporate the changes > if performance can be improved with them. > > regards > marcel > > > Arthur Meyer wrote: > > Hi, > > > > these are the most important issues we have encountered so far: > > > > Increasing the number of nodes in the repository also has a big > > negative effect on the performance of queries. > > When we multiplied our content by four, our queries took > about twice > > as much time to execute. > > Hopefully, Lucene 2.0 may have improvements here aswell. > > > > The item state cache is limited and can't be configured as far is I > > know. > > Since loading node items from the database is relatively > expensive, we > > would like to be able to cache as much as possible. > > > > Node.isNodeType() calls cause monitor contention in a concurrent > > environment. > > For example, if you use the getUUID() method on nodes a > lot, this will > > become a serious bottleneck. > > "http-18080-Processor8" daemon prio=1 tid=0x08571740 nid=0x79ca > > waiting for monitor entry [0xa97f1000..0xa97f2eb0] > > at > > > org.apache.jackrabbit.core.nodetype.NodeTypeRegistry.getEffectiveNodeT > > yp > > e(NodeTypeRegistry.java:384) > > - waiting to lock <0xb38677c8> (a > > org.apache.jackrabbit.core.nodetype.NodeTypeRegistry) > > at > > > org.apache.jackrabbit.core.NodeImpl.getEffectiveNodeType(NodeImpl.java > > :8 > > 68) > > at > > org.apache.jackrabbit.core.NodeImpl.isNodeType(NodeImpl.java:1245) > > at > > org.apache.jackrabbit.core.NodeImpl.getUUID(NodeImpl.java:2802) > > > > Further, the parsing of nodetype names seems to be a > bottleneck in the > > isNodeType() implementation > > at > > > org.apache.jackrabbit.name.NameFormat.parseIgnoreCache(NameFormat.java > > :2 > > 52) > > at > > org.apache.jackrabbit.name.NameFormat.parse(NameFormat.java:80) > > at > > org.apache.jackrabbit.core.NodeImpl.isNodeType(NodeImpl.java:2552) > > > > Similar monitor contention issues occur in the > > CachingNamespaceResolver class. > > Using the util.concurrent classes could help solving these issues. > > > > Finally, we're also very interested in using jackrabbit in > a clustered > > environment. > > > > Arthur Meyer > >
