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 Fri, 18 May 2018 03:15:00 GMT


Cao Manh Dat commented on SOLR-12338:

[] The need to order things come from how we currently handle reordered
in-place updates. Currently, if a replica receives in-place update u2 which point to in-place
update u1 which does not arrive yet, the replica will fetch the full document from the leader.
This is a very costly/risky logic to handle reordered updates (ie: what if there are no leader
to ask for the full document). Luckily for us that reorder is not a common case right now,
but if we replay updates in a parallel and non-order way, above case can happen much more
frequently. Therefore In my opinion, it should be avoided. 

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