lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael McCandless (JIRA)" <j...@apache.org>
Subject [jira] Resolved: (SOLR-2342) Lock starvation can cause commit to never run when many clients are adding docs
Date Mon, 14 Feb 2011 23:01:57 GMT

     [ https://issues.apache.org/jira/browse/SOLR-2342?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Michael McCandless resolved SOLR-2342.
--------------------------------------

       Resolution: Fixed
    Fix Version/s: 4.0
         Assignee: Michael McCandless

> 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
>            Assignee: Michael McCandless
>            Priority: Minor
>             Fix For: 3.1, 4.0
>
>
> 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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message