On 9/25/23 08:53, Dmitri Maziuk wrote:
On 9/25/23 08:24, Shawn Heisey wrote:
...
Solr 4.7 handles this as the customer wants, but Solr 9.1 doesn't.
This sounds like a race condition, are you sure it's Solr doing the
ordering and not e.g. the network stack?
I have seen the requests in the logs on the two systems that send the
indexing requests and the matching entries in solr.log on 9.x. The
"update" request is sent one millisecond before the "create" request.
The "update" request has quite a bit more field data than the "create"
request, so I am sure it takes longer.
When these requests are sent to a 4.7 cluster, the end result is that
the updated record is kept. I believe this is happening due to how long
the two updates take, and the order of receipt is ignored.
When exactly the same thing is sent to a 9.1.1 cluster, the "create"
record is kept instead of the "update" record. The customer has said
that they think this is a bug in 9.1.1 ... but I think Solr 9 is
actually doing it right, honoring the order the updates were received,
and Solr 4 just happened to meet their expectations due to what I would
call a bug.
What I found is that when the "add" request comes first, 8.11.2 (at
least) will create a new -- useless -- document for it. I wish it failed
instead.
You might be able to achieve the behavior you want with the optimistic
concurrency feature:
https://solr.apache.org/guide/solr/latest/indexing-guide/partial-document-updates.html#optimistic-concurrency
Maybe this feature can also help in my customer's setup.
Thanks,
Shawn
