lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Muir (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (SOLR-7606) ToParentBlockJoinQuery fails with AIOOBE under certain circumstances
Date Fri, 29 May 2015 09:29:19 GMT

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

Robert Muir commented on SOLR-7606:
-----------------------------------

Sorry, this is a solr bug.

-1 to changing this query, to check that you abused things wrongly at indexing time. I'm sorry,
this is not the job of lucene's queries, and we will slow them for everyone by doing this
stuff. 

We gotta draw a line and let queries be fast, that is why we do indexing at all!

> ToParentBlockJoinQuery fails with AIOOBE under certain circumstances
> --------------------------------------------------------------------
>
>                 Key: SOLR-7606
>                 URL: https://issues.apache.org/jira/browse/SOLR-7606
>             Project: Solr
>          Issue Type: Bug
>    Affects Versions: 4.10.4
>            Reporter: Uwe Schindler
>            Assignee: Uwe Schindler
>         Attachments: LUCENE-6512.patch
>
>
> I had a customer using BlockJoin with Solr. He executed a block join query and the following
appeared in Solr's logs:
> {noformat}
> 28 May 2015 17:19:20  ERROR (SolrException.java:131) - java.lang.ArrayIndexOutOfBoundsException:
-1
>         at org.apache.lucene.codecs.lucene40.BitVector.get(BitVector.java:149)
>         at org.apache.lucene.search.join.ToParentBlockJoinQuery$BlockJoinScorer.nextDoc(ToParentBlockJoinQuery.java:293)
>         at org.apache.lucene.search.Weight$DefaultBulkScorer.scoreAll(Weight.java:192)
>         at org.apache.lucene.search.Weight$DefaultBulkScorer.score(Weight.java:163)
>         at org.apache.lucene.search.BulkScorer.score(BulkScorer.java:35)
>         at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:621)
>         at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:297)
>         at org.apache.solr.search.SolrIndexSearcher.buildAndRunCollectorChain(SolrIndexSearcher.java:209)
>         at org.apache.solr.search.SolrIndexSearcher.getDocListNC(SolrIndexSearcher.java:1619)
>         at org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:1433)
>         at org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:514)
>         at org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:484)
>         at org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:218)
>         at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135)
>         at org.apache.solr.core.SolrCore.execute(SolrCore.java:1976)
>         at org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:777)
>         at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:418)
>         at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:207)
>         at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
>         at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
>         at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
>         at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
>         at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
>         at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
>         at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
>         at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298)
>         at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:852)
>         at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:588)
>         at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:489)
>         at java.lang.Thread.run(Thread.java:745)
> {noformat}
> I debugged this stuff and found out when this happens:
> The last block of documents was not followed by a parent. If one of the child documents
without a parent at the end of the index match the inner query, scorer calls nextSetBit()
to find next parent document. This returns -1. There is an assert afterwards that checks for
-1, but in production code, this is of course never executed.
> If the index has deletetions the false -1 is passed to acceptDocs and then triggers the
above problem.
> We should change the assert to another IllegalStateException() which is used to notify
the user if the orthogonality is broken. By that the user gets the information that his index
is broken and contains child documents without a parent at the very end of a segment.
> I have seen this on 4.10.4. Maybe thats already fixed in 5.0, but I just open this here
for investigation. This was clearly a problem in the index, but due to Solr's buggy implementation
of parent/child documents (you have to set the parent flag in contrast to Elasticsearch on
your own - which is stupid!!!) this was not detected at indexing time. We should open an issue
in Solr to fix this bad behaviour and make solr automatically add the parent field (it only
adds a "_root_" field automatically, maybe it should also add a "_parent_" field automatically).



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

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message