[
https://issues.apache.org/jira/browse/SOLR-12833?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18131218#comment-18131218
]
Nick Shanin commented on SOLR-12833:
------------------------------------
🤖 _AI text below_ 🤖 _(reviewed by Nick Shanin)_
Status check on this ticket, from its own history: it was closed in February
2019, then reopened by [~ab] in April 2019 for a specific regression: the
change grew {{VersionBucket}} from about 24 to about 104 bytes, which put
roughly 0.7 GB of extra heap on a 100-core node. The follow-up work happened
here on the reopened ticket: the two-implementation bucket split (PR 641), a
wait-timeout fix (PR 661), and a test fix (PR 663), and the thread ends with
[~ab] confirming the content is present on the 7.x branches. That work shipped
in 8.1 and 7.7.2, which is why those fixVersions were added after the reopen.
Nothing has moved here since May 2019, and the ticket still sits Reopened with
a Fixed resolution. It looks ready to close as Fixed.
> Use timed-out lock in DistributedUpdateProcessor
> ------------------------------------------------
>
> Key: SOLR-12833
> URL: https://issues.apache.org/jira/browse/SOLR-12833
> Project: Solr
> Issue Type: Improvement
> Components: update, UpdateRequestProcessors
> Affects Versions: 7.5, 8.0
> Reporter: jefferyyuan
> Assignee: Mark Miller
> Priority: Blocker
> Fix For: 7.7, 7.7.2, 8.0, 8.1
>
> Attachments: SOLR-12833-noint.patch, SOLR-12833.patch,
> SOLR-12833.patch, threadDump.txt
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> There is a synchronize block that blocks other update requests whose IDs fall
> in the same hash bucket. The update waits forever until it gets the lock at
> the synchronize block, this can be a problem in some cases.
>
> Some add/update requests (for example updates with spatial/shape analysis)
> like may take time (30+ seconds or even more), this would the request time
> out and fail.
> Client may retry the same requests multiple times or several minutes, this
> would make things worse.
> The server side receives all the update requests but all except one can do
> nothing, have to wait there. This wastes precious memory and cpu resource.
> We have seen the case 2000+ threads are blocking at the synchronize lock, and
> only a few updates are making progress. Each thread takes 3+ mb memory which
> causes OOM.
> Also if the update can't get the lock in expected time range, its better to
> fail fast.
>
> We can have one configuration in solrconfig.xml:
> updateHandler/versionLock/timeInMill, so users can specify how long they want
> to wait the version bucket lock.
> The default value can be -1, so it behaves same - wait forever until it gets
> the lock.
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
