[
https://issues.apache.org/jira/browse/JCR-3242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcel Reutegger updated JCR-3242:
----------------------------------
Attachment: JCR-3242.patch
I reviewed the patch and looked at why the tests fail in the second run.
The problem is an optimization implemented in lucene 3.1: LUCENE-2770
The optimization tries to get hold of sub readers to perform searches
on each segment individually. During that process it 'unwraps' the
Jackrabbit ReadOnlyIndexReaders and accesses the underlying IndexReader
directly. This short cuts our handling of deleted docs in
ReadOnlyIndexReaders (remember we do that to avoid a more expensive
re-open) and resurrects documents that were deleted in an Jackrabbit
index merge. The index merge uses mentioned ReadOnlyIndexReaders.
This can be prevented by implementing getSequentialSubReaders() in
our IndexReader classes and return null.
Some of the changes to the tests were hiding that issue because
additional index flushes were performed. I removed those again.
The method FSDirectoryManager.touchFile() was marked deprecated.
I don't think that's useful, since it is a method that must be
implemented anyway and is marked as deprecated in the interface.
The maxFieldLength was commented out and not respected anymore.
I removed the property from the AbstractIndex and the handling
is now in SearchIndex, where the Analyzer is wrapped with a
LimitTokenCountAnalyzer.
The compound file parameter did not have an effect anymore.
MergePolicy.setNoCFSRatio(1.0) fixed it.
I removed the duplicate code for sub reader indexes and start
in SearchIndex.CombinedIndexReader and CachingMultiIndexReader.
This functionality is now accessible in the base class.
The JackrabbitQueryParser used new Lucene 3.6 settings, which
resulted in a different parser behaviour. I think it's easiest
to just stick with 2.4, even if it is marked deprecated.
The changes in TestHelper are not needed for the lucene upgrade.
The docsScoredInOrder parameter was flipped in
SortedLuceneQueryHits.getHits(). Instead I looked at what fails
if we keep the current implementation. I think the culprit is
the topScorer flag in our Query classes. They all just pass the
value as is to sub scorer even though they are obviously not
top scorers. Passing false in that cases seems to fix the issue.
Please note that this patch also includes my recently proposed
changes for JCR-3337. Otherwise the tests would not succeed.
> Update to Lucene 3.6
> --------------------
>
> Key: JCR-3242
> URL: https://issues.apache.org/jira/browse/JCR-3242
> Project: Jackrabbit Content Repository
> Issue Type: Improvement
> Components: jackrabbit-core
> Affects Versions: 2.4.1
> Reporter: Sascha Rodekamp
> Labels: patch
> Attachments: JCR-3242-jr-core-v0.patch, JCR-3242.patch,
> JCR-3242_lucene_update_3.5.patch, JCR-3242_lucene_update_3.5.patch,
> JCR-3242_lucene_update_3.6.patch, JCR-3242_lucene_update_3.6_v2.patch,
> JCR-3242_lucene_update_3.6_v3.patch, lucene_3.6.0_updated.patch,
> surefire-reports.7z, surefire-reports.7z
>
>
> Hi,
> i want to update lucene to version 3.5. After making a few code changes the
> tests fail.
> I'll attach the patch with the changes plus the surfire logs. It would be
> great if someone found the time to have a short look and have an idea how to
> fix this issue.
> Main Problem:
> Caused by: java.lang.UnsupportedOperationException: IndexReader is read-only
> at
> org.apache.jackrabbit.core.query.lucene.ReadOnlyIndexReader.doCommit(ReadOnlyIndexReader.java:175)
> at org.apache.lucene.index.IndexReader.commit(IndexReader.java:1464)
> at org.apache.lucene.index.MultiReader.doCommit(MultiReader.java:413)
> at org.apache.lucene.index.IndexReader.commit(IndexReader.java:1464)
> at org.apache.lucene.index.IndexReader.commit(IndexReader.java:1450)
> at org.apache.lucene.index.IndexReader.decRef(IndexReader.java:273)
> at org.apache.lucene.index.IndexReader.close(IndexReader.java:1479)
> at
> org.apache.jackrabbit.core.query.lucene.CachingMultiIndexReader.release(CachingMultiIndexReader.java:157)
> at
> org.apache.jackrabbit.core.query.lucene.MultiIndex.releaseMultiReader(MultiIndex.java:1001)
> at
> org.apache.jackrabbit.core.query.lucene.MultiIndex.safeFlush(MultiIndex.java:1318)
> at
> org.apache.jackrabbit.core.query.lucene.Recovery.run(Recovery.java:170)
> at
> org.apache.jackrabbit.core.query.lucene.Recovery.run(Recovery.java:84)
> at
> org.apache.jackrabbit.core.query.lucene.MultiIndex.<init>(MultiIndex.java:314)
> at
> org.apache.jackrabbit.core.query.lucene.SearchIndex.doInit(SearchIndex.java:555)
> at
> org.apache.jackrabbit.core.query.AbstractQueryHandler.init(AbstractQueryHandler.java:78)
> at
> org.apache.jackrabbit.core.config.RepositoryConfigurationParser$1.getQueryHandler(RepositoryConfigurationParser.java:655)
> at
> org.apache.jackrabbit.core.config.RepositoryConfig.getQueryHandler(RepositoryConfig.java:1037)
> at
> org.apache.jackrabbit.core.SearchManager.<init>(SearchManager.java:171)
> at
> org.apache.jackrabbit.core.RepositoryImpl.getSystemSearchManager(RepositoryImpl.java:607)
> at
> org.apache.jackrabbit.core.RepositoryImpl.access$100(RepositoryImpl.java:124)
> at
> org.apache.jackrabbit.core.RepositoryImpl$WorkspaceInfo.getSearchManager(RepositoryImpl.java:1855)
> at
> org.apache.jackrabbit.core.RepositoryImpl$WorkspaceInfo.doPostInitialize(RepositoryImpl.java:2092)
> at
> org.apache.jackrabbit.core.RepositoryImpl$WorkspaceInfo.initialize(RepositoryImpl.java:1997)
> at
> org.apache.jackrabbit.core.RepositoryImpl.initStartupWorkspaces(RepositoryImpl.java:510)
> at
> org.apache.jackrabbit.core.RepositoryImpl.<init>(RepositoryImpl.java:318)
> at
> org.apache.jackrabbit.core.RepositoryImpl.create(RepositoryImpl.java:582)
> at
> org.apache.jackrabbit.core.JackrabbitRepositoryStub.createRepository(JackrabbitRepositoryStub.java:185)
> at
> org.apache.jackrabbit.core.JackrabbitRepositoryStub.getOrCreateRepository(JackrabbitRepositoryStub.java:193)
> at
> org.apache.jackrabbit.core.JackrabbitRepositoryStub.getRepository(JackrabbitRepositoryStub.java:156)
> ... 19 more
> Best Regards,
> Sascha
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
