[ 
https://issues.apache.org/jira/browse/SOLR-12338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16492538#comment-16492538
 ] 

Cao Manh Dat commented on SOLR-12338:
-------------------------------------

{quote}
The hot while loop of map.putIfAbsent seems fishy to me. Even if it may be rare 
in practice, I wonder if we can do something simpler? You may get luck with 
map.compute* methods on ConcurrentHashMap which execute the lambda atomically. 
Though I don't know if it's bad to block if we try to acquire a lock within 
there. I see remove() removes the value of the Map but perhaps it the value 
were a mechanism that tracked that there's a producer pending, then we should 
not remove the value from the lock? If we did this, then maybe that would 
simplify add()? I'm not sure.
{quote}
After putting more thought on this, Change the remove method to this one seems 
to solve the problem.
{code}
    public void remove(T t) {
      // There can be many threads are waiting for this lock
      map.remove(t).release(Integer.MAX_VALUE);
      sizeLock.release();
    }
{code}
In short of the idea of SetBlockingQueue.add(T t) is 
# all participations will try to call {{map.putIfAbsent(t, myLock)}}, 
# only one will win, other participations will have to wait for the lock of the 
winner
# when the winner get removed from the set, it also release + remove its lock
# back to 1.

> 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
>
>
> 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]

Reply via email to