[ https://issues.apache.org/jira/browse/SOLR-2342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12990554#comment-12990554 ]
Michael McCandless commented on SOLR-2342: ------------------------------------------ Fixing the client threads to not commit in the end, so no client is committing, and then turning on Solr's auto-commit, still hits the starvation. > Lock starvation can cause commit to never run when many clients are adding > docs > ------------------------------------------------------------------------------- > > Key: SOLR-2342 > URL: https://issues.apache.org/jira/browse/SOLR-2342 > Project: Solr > Issue Type: Bug > Components: update > Reporter: Michael McCandless > Priority: Minor > > I have a stress test, where 100 clients add 100 1MB docs and then call commit > in the end. It's a falldown test (try to make Solr fall down) and nowhere > near "actual" usage. > But, after some initial commits that succeed, I'm seeing later commits always > time out (client side timeout @ 10 minutes). Watching Solr's logging, no > commit ever runs. > Looking at the stack traces in the threads, this is not deadlock: the > add/update calls are running, and new segments are being flushed to the index. > Digging in the code a bit, we use ReentrantReadWriteLock, with add/update > acquiring the readLock and commit acquiring the writeLock. But, according to > the jdocs, the writeLock isn't given any priority over the readLock (unless > you set fairness, which we don't). So I think this explains the starvation? > However, this is not a real world use case (most apps would/should call > commit less often, and from on client). Also, we could set fairness, but it > seems to have some performance penalty, and I'm not sure we should penalize > the "normal" case for this unusual one. EG see here (thanks Mark): > http://www.javaspecialists.eu/archive/Issue165.html. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org