You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Hoss Man (JIRA)" <ji...@apache.org> on 2016/07/02 01:15:11 UTC

[jira] [Updated] (SOLR-9235) Indexing stuck after delete by range query

     [ https://issues.apache.org/jira/browse/SOLR-9235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Hoss Man updated SOLR-9235:
---------------------------
    Attachment: SOLR-9235.patch

an NPE would never be intentional - Mikhail is just pointing out when he thiks it broke, and from what i can tell he's right.

Attached patch beefs up TestRangeQuery to demonstrate this bug (and in general to better exercise more code paths in SolrRangeQuery which can vary based on whether the number of terms is mall enough to re-write to a BooleanQuery or not).

The added tests can ail very easily demonstrating the same problem reported here, and i added (what seems to me like) a trivial fix - if we don't have a SolrIndexSearcher (which we don't when IndexWriter processes a DBQ) then completley bypass all the "doCheck" logic and fall through the the more classic TermEnum + DocIdSetBuilder iteration.

[~yonik@apache.org] - does this look correct to you?

> Indexing stuck after delete by range query
> ------------------------------------------
>
>                 Key: SOLR-9235
>                 URL: https://issues.apache.org/jira/browse/SOLR-9235
>             Project: Solr
>          Issue Type: Bug
>          Components: query parsers
>    Affects Versions: 6.0.1, 6.1
>            Reporter: Anders Melchiorsen
>         Attachments: SOLR-9235.patch
>
>
> Upgrading from Solr 4.0.0 to 6.0.1/6.1.0, this old query suddenly got our indexing stuck:
> {noformat}
> <delete><query>lastdate_a:{* TO 20160620} AND lastdate_p:{* TO 20160620} AND country:9</query></delete>
> {noformat}
> with this error logged:
> {noformat}
> 2016-06-20 02:20:36.429 ERROR (commitScheduler-15-thread-1) [   x:mycore] o.a.s.u.CommitTracker auto commit error...:java.lang.NullPointerException
>         at org.apache.solr.query.SolrRangeQuery.createDocSet(SolrRangeQuery.java:156)
>         at org.apache.solr.query.SolrRangeQuery.access$200(SolrRangeQuery.java:57)
>         at org.apache.solr.query.SolrRangeQuery$ConstWeight.getSegState(SolrRangeQuery.java:412)
>         at org.apache.solr.query.SolrRangeQuery$ConstWeight.scorer(SolrRangeQuery.java:484)
>         at org.apache.lucene.search.LRUQueryCache$CachingWrapperWeight.scorer(LRUQueryCache.java:617)
>         at org.apache.lucene.search.BooleanWeight.scorer(BooleanWeight.java:389)
>         at org.apache.solr.update.DeleteByQueryWrapper$1.scorer(DeleteByQueryWrapper.java:89)
>         at org.apache.lucene.index.BufferedUpdatesStream.applyQueryDeletes(BufferedUpdatesStream.java:694)
>         at org.apache.lucene.index.BufferedUpdatesStream.applyDeletesAndUpdates(BufferedUpdatesStream.java:262)
>         at org.apache.lucene.index.IndexWriter.applyAllDeletesAndUpdates(IndexWriter.java:3187)
>         at org.apache.lucene.index.IndexWriter.maybeApplyDeletes(IndexWriter.java:3173)
>         at org.apache.lucene.index.IndexWriter.prepareCommitInternal(IndexWriter.java:2825)
>         at org.apache.lucene.index.IndexWriter.commitInternal(IndexWriter.java:2989)
>         at org.apache.lucene.index.IndexWriter.commit(IndexWriter.java:2956)
>         at org.apache.solr.update.DirectUpdateHandler2.commit(DirectUpdateHandler2.java:619)
>         at org.apache.solr.update.CommitTracker.run(CommitTracker.java:217)
>         at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
>         at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>         at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
>         at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
>         at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>         at java.lang.Thread.run(Thread.java:745)
> {noformat}
> The types were:
> {noformat}
>   <fieldType name="string" class="solr.StrField" sortMissingLast="true" omitNorms="true"/>
>   <field name="lastdate_a" type="string" indexed="true" stored="false" />
>   <field name="lastdate_p" type="string" indexed="true" stored="false" />
>   <field name="country" type="string" indexed="true" stored="true" multiValued="true" />
> {noformat}
> but changing the date fields into "integer" seems to avoid the problem:
> {noformat}
>   <fieldType name="integer" class="solr.TrieIntField" omitNorms="true"/>
> {noformat}



--
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