[
https://issues.apache.org/jira/browse/SOLR-12338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16494504#comment-16494504
]
Cao Manh Dat commented on SOLR-12338:
-------------------------------------
{quote}But then I wonder if we can move the sizeSemaphore.release to before the
countDown? The principle at play here is to release locks in the reverse order
that they were acquired. That's how it's normally done to, I think, prevent
deadlock cases, though I'm not sure it's possible here as-coded.
{quote}
The order or unlocking here does not matter. To call {{remove}} a thread must
hold both locks. Therefore won't cause deadlock.
{quote}ah; I think I can see why we acquire the size semaphore after getting
the striped lock. we don't want to use up a permit that might lock on an ID
first.
{quote}
Correct, multiple threads on a lockId can eat up size semaphore.
Thanks [~dsmiley], the replacement of using CountDownlatch and javadocs is
good. But I don't see any improvement of using a new loop?
> Replay buffering tlog in parallel
> ---------------------------------
>
> Key: SOLR-12338
> URL: https://issues.apache.org/jira/browse/SOLR-12338
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: Cao Manh Dat
> Assignee: Cao Manh Dat
> Priority: Major
> Attachments: SOLR-12338.patch, SOLR-12338.patch, SOLR-12338.patch,
> SOLR-12338.patch, SOLR-12338.patch
>
>
> Since updates with different id are independent, therefore it is safe to
> replay them in parallel. This will significantly reduce recovering time of
> replicas in high load indexing environment.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
