lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Cao Manh Dat (JIRA)" <>
Subject [jira] [Commented] (SOLR-12338) Replay buffering tlog in parallel
Date Tue, 29 May 2018 23:57:00 GMT


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.
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. 
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:
>             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,
> 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

This message was sent by Atlassian JIRA

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message