[ 
https://issues.apache.org/jira/browse/LUCENE-6984?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15108283#comment-15108283
 ] 

Alan Woodward commented on LUCENE-6984:
---------------------------------------

I found this through the highlighting code in luwak, where we rewrite queries 
into their Span equivalents.  MultiTermQueries are wrapped in 
SpanMultiTermQueryWrapper, which alters the inner query's RewriteMethod.  If 
the MTQ is within a deeply-nested BooleanQuery then this invalidates the 
query's hashcode, and the assertion trips the next time the query is used.

I can see a few ways to solve this:
* make MTQ immutable, and rework SpanMTQWrapper so that it uses its inner 
query's TermsEnum to rewrite itself rather than altering the inner query's 
rewrite method directly
* make MTQ cloneable, and use a copy of the query in SpanMTQWrapper rather than 
altering the query directly
* stop caching the hashcode on BooleanQuery

I think we probably need to stop the caching anyway, because there's no way to 
guarantee that any query passed to BQ is itself immutable, but it's also worth 
making our core queries immutable if we can.

> MultiTermQuery mutability can cause assertion failures in BooleanQuery
> ----------------------------------------------------------------------
>
>                 Key: LUCENE-6984
>                 URL: https://issues.apache.org/jira/browse/LUCENE-6984
>             Project: Lucene - Core
>          Issue Type: Bug
>            Reporter: Alan Woodward
>
> BooleanQuery caches its hashcode on the grounds that it is immutable.  
> However, this immutability doesn't hold if some of its clauses hold queries 
> that are not themselves immutable - for example, a MultiTermQuery with a 
> changeable rewrite method.  If one of these clauses is mutated after the 
> hashcode has been calculated, then the next time the parent BooleanQuery is 
> used the assertion in BooleanQuery.hashCode() will fail.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to