jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dennis van der Laan <d.g.van.der.l...@rug.nl>
Subject Re: Nodes not returned in query when indexing?
Date Fri, 02 Oct 2009 08:46:46 GMT
Marcel Reutegger wrote:
> Hi,
> On Tue, Sep 29, 2009 at 10:38, Dennis van der Laan
> <d.g.van.der.laan@rug.nl> wrote:
>> Hi,
>> I believe file nodes get 'hidden' somehow when their contents get indexed.
>> I create a file in a repository, and set a custom property 'myns:id' on
>> the jcr:content node. Directly after creating the file, I perform an
>> XPath query retrieving the file node based on the id-property.
>> Sometimes, especially with (larger) PDF-files, the node can not be found
>> by this id-property.
>> I changed my code, by executing the query over and over again and
>> waiting for 2 seconds between each try. Eventually the node is returned,
>> mostly after 4-6 seconds (so 2 to 3 tries). In the log file, when the
>> query does not return the node, I see the message "MultiIndex: updating
>> index with 1 nodes from indexing queue. (MultiIndex.java, line 1210)",
>> letting me believe the node is somehow hidden or locked when it is being
>> indexed.
>> I have seen this behavior when using a direct repository and when using
>> RMI. It happens when using a local filesystem and when using a database
>> store, with Java Derby and with Oracle 10.
>> My questions:
>> - Is this 'normal' behavior or is it a bug?
> this sounds like a bug. what version of jackrabbit are you using?
I have the same behavior using Jackrabbit 1.5.6 and 1.6.0.
I discovered setting the extractorPoolSize to 0 in my repository
configuration 'fixes' the problem, but this has a significant impact on
the upload performance.

best regards,
> regards
>  marcel
>> - How can I prevent this? Would it e.g. help if I exclude the
>> id-property from being indexed, or will the complete jcr:content node be
>> hidden when the jcr:data property is being indexed?
>> Thanks in advance,
>> Dennis van der Laan

  • Unnamed multipart/mixed (inline, None, 0 bytes)
View raw message