It looks like the usage of Lucene 2.0 is already possible:
http://issues.apache.org/jira/browse/JCR-352 (see provided patches).

I am quite curious if this is solving the problems Arthur is
mentioning in this thread.

./alex
--
.w( the_mindstorm )p.

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

Reply via email to