[
https://issues.apache.org/jira/browse/JCR-2980?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13042219#comment-13042219
]
Alex Parvulescu commented on JCR-2980:
--------------------------------------
ouch, I've been looking at this all day and I can't figure it out :)
the extraction logic has changed a bit, also the lucene version, but still I
can't put my finger on it.
I still think that the test was good enough to check what is going on in that
small window when the processing happens, but adding the extra properties to
the node copy seems to introduce some problems.
also, apparently running the failing tests
(IndexingAggregateTest.testNtFileAggregate and
IndexingQueueTest.testInitialIndex) 2 times makes them pass, so I'd point to
the sync logic between the extraction and current session, but I'm not sure.
comments are always welcome
> 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
