lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Erick Erickson <>
Subject Re: AW: AW: SolrClient#updateByQuery?
Date Sat, 27 Jan 2018 17:19:54 GMT

Let's not raise a JIRA quite yet. I am 99% sure your test is not doing
what you think or you have some invalid expectations. This is such a
fundamental feature that it'd surprise me a _lot_ if it were a bug.
Also, there are a bunch of DeleteByQuery tests in the junit tests
that's run all the time..

Wait, are you issuing an explicit commit or not? I saw this phrase
"...brutely by forcing a commit (with "expunge deletes")..." and saw
the word "commit" and assumed you were issuing a commit, but
re-reading that's not clear at all. Code should look something like

query to see if doc is gone.

So here's what I'd try next:

1> Issue an explicit commit command (SolrCient.commit()) after the
DBQ. The defaults there are openSearcher = true and waitSearcher=
true. When that returns _then_ issue your query.
2> If that doesn't work, try (just for information gathering) waiting,
several seconds after the commit to try your request. This should
_not_ be necessary, but it'll give us a clue what's going on.
3> Show us the code if you can.


On Sat, Jan 27, 2018 at 6:55 AM, Clemens Wyss DEV <> wrote:
> Erick said/wrote:
>> If you commit after docs are deleted and _still_ see them in search results, that's
> should I JIRA it?
> -----Ursprüngliche Nachricht-----
> Von: Shawn Heisey []
> Gesendet: Samstag, 27. Januar 2018 12:05
> An:
> Betreff: Re: AW: AW: SolrClient#updateByQuery?
> On 1/27/2018 12:49 AM, Clemens Wyss DEV wrote:
>> Thanks for all these (main contributor's 😉) valuable inputs!
>> First thing I did was getting getting rid of "expungeDeletes". My
>> "single-deletion" unittest failed unti I added the optimize-param
>>> updateReques.setParam( "optimize", "true" );
>> Does this make sense or should JIRA it?
>> How expensive ist this "optimization"?
> An optimize operation is a complete rewrite of the entire index to one segment.  It will
typically double the size of the index.  The rewritten index will not have any documents that
were deleted in it.  It's slow and extremely expensive.  If the index is one gigabyte, expect
an optimize to take at least half an hour, possibly longer, to complete.
> The CPU and disk I/O are going to take a beating while the optimize is occurring.
> Thanks,
> Shawn

View raw message