[ https://issues.apache.org/jira/browse/SOLR-12833?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16763030#comment-16763030 ]
Cassandra Targett edited comment on SOLR-12833 at 2/7/19 7:57 PM: ------------------------------------------------------------------ [~markrmil...@gmail.com], I think this can be resolved? It appears in the CHANGES for 7.7, so it being open and only marked for 8.0 makes me unsure. was (Author: ctargett): [~markrmil...@gmail.com], I think this be resolved? It appears in the CHANGES for 7.7, so it being open and only marked for 8.0 makes me unsure. > Use timed-out lock in DistributedUpdateProcessor > ------------------------------------------------ > > Key: SOLR-12833 > URL: https://issues.apache.org/jira/browse/SOLR-12833 > Project: Solr > Issue Type: Improvement > Security Level: Public(Default Security Level. Issues are Public) > Components: update, UpdateRequestProcessors > Affects Versions: 7.5, 8.0 > Reporter: jefferyyuan > Assignee: Mark Miller > Priority: Minor > Fix For: 8.0 > > Attachments: SOLR-12833.patch, SOLR-12833.patch > > 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 (v7.6.3#76005) --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org