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

ASF subversion and git services commented on SOLR-7625:
-------------------------------------------------------

Commit 1683175 from [~thelabdude] in branch 'dev/branches/branch_5x'
[ https://svn.apache.org/r1683175 ]

SOLR-7625: Ensure that the max value for seeding version buckets is updated 
after recovery even if the UpdateLog is not replayed.

> Version bucket seed not updated after new index is installed on a replica
> -------------------------------------------------------------------------
>
>                 Key: SOLR-7625
>                 URL: https://issues.apache.org/jira/browse/SOLR-7625
>             Project: Solr
>          Issue Type: Bug
>          Components: SolrCloud
>    Affects Versions: 5.2
>            Reporter: Timothy Potter
>            Assignee: Timothy Potter
>            Priority: Blocker
>             Fix For: 5.2
>
>         Attachments: SOLR-7625.patch
>
>
> This is related to SOLR-7332 ... I used to set the highest value on the 
> version buckets based on a lookup to the index whenever a firstSearcher event 
> fired, but that led to reentrant lock issues (see SOLR-7587), so I moved that 
> version seeding code into the SolrCore constructor.
> While working on SOLR-4506, I just realized that if a core has to pull index 
> files from the leader to recover, then the version bucket doesn't get updated 
> once the new index files are pulled over. In other words, the code seeds the 
> version buckets during core init, but if the underlying index changes due to 
> being too far out-of-date, then the version buckets are never updated once 
> the new index is in place. The risk is that if bucket versions are seeded 
> with a value that is too low, then it can lead to correctness issues with 
> versioned updates.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to