I've noticed something weird since implementing the change Shawn suggested,
I wonder if someone can shed some light on it:
Since changing from delete by query _root_:.. to querying for ids _root_:
and then deleteById(ids from root query), we have started to notice some
facet counts for child docum
Thanks Mike, I will experiment with that and see if it does anything for
this particular issue.
I implemented Shawn's workaround and the problem has gone away, so that is
good at least for the time being.
Do we think that this is something that should be tracked in JIRA for 6.X?
Or should I confi
I'm not sure this is what's affecting you, but you might try upgrading to
Lucene/Solr 7.1; in 7.0 there were big improvements in using multiple
threads to resolve deletions:
http://blog.mikemccandless.com/2017/07/lucene-gets-concurrent-deletes-and.html
Mike McCandless
http://blog.mikemccandless.c
@Erick, I see, thanks for the clarification.
@Shawn, Good idea for the workaround! I will try that and see if it
resolves the issue.
Thanks,
Chris
On Tue, Nov 7, 2017 at 1:09 PM, Erick Erickson
wrote:
> bq: you think it is caused by the DBQ deleting a document while a
> document with that sam
bq: you think it is caused by the DBQ deleting a document while a
document with that same ID
No. I'm saying that DBQ has no idea _if_ that would be the case so
can't carry out the operations in parallel because it _might_ be the
case.
Shawn:
IIUC, here's the problem. For deleteById, I can guaran
On 11/5/2017 12:20 PM, Chris Troullis wrote:
> The issue I am seeing is when some
> threads are adding/updating documents while other threads are issuing
> deletes (using deleteByQuery), solr seems to get into a state of extreme
> blocking on the replica
The deleteByQuery operation cannot coexist
If I am understanding you correctly, you think it is caused by the DBQ
deleting a document while a document with that same ID is being updated by
another thread? I'm not sure that is what is happening here, as we only
delete docs if they no longer exist in the DB, so nothing should be
adding/updati
Maybe not a relevant fact on this, but: "addAndDelete" is triggered by
"*Reordering
of DBQs'; *that means there are non-executed DBQs present in the updateLog
and an add operation is also received. Solr makes sure DBQs are executed
first and than add operation is executed.
Amrit Sarkar
Search Engi
Well, consider what happens here.
Solr gets a DBQ that includes document 132 and 10,000,000 other docs
Solr gets an add for document 132
The DBQ takes time to execute. If it was processing the requests in
parallel would 132 be in the index after the delete was over? It would
depend on when the DB
As an update, I have confirmed that it doesn't seem to have anything to do
with child documents, or standard deletes, just deleteByQuery. If I do a
deleteByQuery on any collection while also adding/updating in separate
threads I am experiencing this blocking behavior on the non-leader replica.
Has
Hi,
I am experiencing an issue where threads are blocking for an extremely long
time when I am indexing while deleteByQuery is also running.
Setup info:
-Solr Cloud 6.6.0
-Simple 2 Node, 1 Shard, 2 replica setup
-~12 million docs in the collection in question
-Nodes have 64 GB RAM, 8 CPUs, spinni
11 matches
Mail list logo
