Return-Path: X-Original-To: apmail-jackrabbit-dev-archive@www.apache.org Delivered-To: apmail-jackrabbit-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id EC9356B50 for ; Sun, 5 Jun 2011 04:42:22 +0000 (UTC) Received: (qmail 77340 invoked by uid 500); 5 Jun 2011 04:42:22 -0000 Delivered-To: apmail-jackrabbit-dev-archive@jackrabbit.apache.org Received: (qmail 77125 invoked by uid 500); 5 Jun 2011 04:42:14 -0000 Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@jackrabbit.apache.org Delivered-To: mailing list dev@jackrabbit.apache.org Received: (qmail 77116 invoked by uid 99); 5 Jun 2011 04:42:09 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 05 Jun 2011 04:42:09 +0000 X-ASF-Spam-Status: No, hits=-2000.0 required=5.0 tests=ALL_TRUSTED,T_RP_MATCHES_RCVD X-Spam-Check-By: apache.org Received: from [140.211.11.116] (HELO hel.zones.apache.org) (140.211.11.116) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 05 Jun 2011 04:42:07 +0000 Received: from hel.zones.apache.org (hel.zones.apache.org [140.211.11.116]) by hel.zones.apache.org (Postfix) with ESMTP id 5E59D100D88 for ; Sun, 5 Jun 2011 04:41:47 +0000 (UTC) Date: Sun, 5 Jun 2011 04:41:47 +0000 (UTC) From: "Alex Parvulescu (JIRA)" To: dev@jackrabbit.apache.org Message-ID: <701240233.69338.1307248907383.JavaMail.tomcat@hel.zones.apache.org> In-Reply-To: <997904360.48795.1306506887457.JavaMail.tomcat@hel.zones.apache.org> Subject: [jira] [Commented] (JCR-2980) Nodes that have properties marked for async extraction should be available for querying MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/JCR-2980?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13044431#comment-13044431 ] Alex Parvulescu commented on JCR-2980: -------------------------------------- I have finally figured it out. It was my change that triggered this issue, in fact the TokenStream that I was passing to the node's copy was not meant to be consumed more than once, so sometimes the copy consumed the data, leaving nothing else for the real node. To be more exact, when the extraction was slow, it passed to the background. If this happened, the real node would loose its original data, because of the TokenStream. The fix was to add 'reset' and 'close' methods to the SingletonTokenStream, so that it can be consumed mode than once. > Nodes that have properties marked for async extraction should be available for querying > --------------------------------------------------------------------------------------- > > Key: JCR-2980 > URL: https://issues.apache.org/jira/browse/JCR-2980 > Project: Jackrabbit Content Repository > Issue Type: Bug > Components: indexing > Affects Versions: 2.3.0 > Reporter: Alex Parvulescu > Assignee: Alex Parvulescu > Fix For: 2.3.0 > > > The problems only appears when dealing with nodes that have async extractors. In this case we return a lightweight copy of the node (without the property that will be processed in the background). > The copy algorithm ignores certain field types (that have been probably introduced during the Lucene 3 upgrade, not sure) such as SingletonTokenStream(s). > So the lightweight copy does not include all the existing properties, therefore the node will not appear in queries during the extraction time. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira