On 9/25/23 09:44, Walter Underwood wrote:
Updates and indexing used to be single-threaded. A while ago (maybe in Solr 
6.x?), a bunch of locking was removed so that indexing could use multiple CPUs. 
That is probably what you are seeing.

I don’t think Solr has ever guaranteed ordering for updates, even if it 
happened to work.

Maybe use a real-time get before the update to check whether the document is 
really there? That should be pretty fast.

Because the two requests are sent by different services and coordinating those requests woud likely be difficult, I think the simplest change that would fix the problem is to use optimistic concurrency, setting the field to 0 on the "create" request so the request fails if the document already exists. And of course the resulting error would need to be explicitly detected so it can be ignored, while still correctly handling other errors. I have not seen the SolrJ code that actually makes the indexing requests.

In this, I am assuming, hopefully correctly, that optimistic concurrency checks uncommitted docs like the /get handler, as it is very unlikely that the earlier update has actually been committed when the second update comes in.

Thanks,
Shawn

Reply via email to