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