[
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
