[
https://issues.apache.org/jira/browse/SOLR-7488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14519752#comment-14519752
]
Hoss Man commented on SOLR-7488:
--------------------------------
Here's the code in question...
{noformat}
897383 koji // get FastVectorHighlighter instance out of the
processing loop
897383 koji FastVectorHighlighter fvh = new FastVectorHighlighter(
897383 koji // FVH cannot process hl.usePhraseHighlighter
parameter per-field basis
897383 koji params.getBool(
HighlightParams.USE_PHRASE_HIGHLIGHTER, true ),
897383 koji // FVH cannot process hl.requireFieldMatch parameter
per-field basis
990301 koji params.getBool( HighlightParams.FIELD_MATCH, false )
);
1555369 rmuir
fvh.setPhraseLimit(params.getInt(HighlightParams.PHRASE_LIMIT,
SolrHighlighter.DEFAULT_PHRASE_LIMIT));
1167008 rmuir FieldQuery fieldQuery = fvh.getFieldQuery( query,
searcher.getIndexReader() );
639490 klaas
639490 klaas // Highlight each document
639490 klaas DocIterator iterator = docs.iterator();
639490 klaas for (int i = 0; i < docs.size(); i++) {
897383 koji int docId = iterator.nextDoc();
897383 koji Document doc = searcher.doc(docId, fset);
897383 koji NamedList docSummaries = new SimpleOrderedMap();
897383 koji for (String fieldName : fieldNames) {
897383 koji fieldName = fieldName.trim();
897383 koji if( useFastVectorHighlighter( params, schema,
fieldName ) )
990301 koji doHighlightingByFastVectorHighlighter( fvh,
fieldQuery, req, docSummaries, docId, doc, fieldName );
897383 koji else
897383 koji doHighlightingByHighlighter( query, req,
docSummaries, docId, doc, fieldName );
897383 koji }
897383 koji String printId = schema.printableUniqueKey(doc);
897383 koji fragments.add(printId == null ? null : printId,
docSummaries);
897383 koji }
{noformat}
It looks like the bug may have been introduced by r1167008 for LUCENE-1889:
"pass the reader to FVH so it can rewrite multitermqueries" ... because
DefaultSolrHighlighter had previously "optimized" the FVH call out of the loop,
this caused the rewriting to happen even if the user had said they didn't want
FVH.
[~koji] & [~dsmiley] - can one of you sanity check me here? (I don't
understand the surround parser and/or highlighter well enough to try and write
a test case for this)
> suspicious FVH init code in DefaultSolrHighlighter even when FVH should not
> be used
> -----------------------------------------------------------------------------------
>
> Key: SOLR-7488
> URL: https://issues.apache.org/jira/browse/SOLR-7488
> Project: Solr
> Issue Type: Bug
> Affects Versions: 4.10
> Reporter: Hoss Man
>
> Rich Hume reported gettting errors from FastVectorHighlighter, evidently
> while using the the surround query parser, even though he was not trying to
> "useFastVectorHighlighter"
> my naive reading of the code leads me to believe that DefaultSolrHighlighter
> is incorrectly attempting to initialize a FVH instance even when it shouldn't
> be -- which appears to cause failures in cases where the query in use is not
> something that can be handled by the FVH.
> Not sure how to reproduce at the moment -- but the code smells fishy.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
