lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF subversion and git services (JIRA)" <>
Subject [jira] [Commented] (SOLR-12999) Index replication could delete segments first
Date Tue, 14 May 2019 20:39:00 GMT


ASF subversion and git services commented on SOLR-12999:

Commit 371d645e6add019675ab3c468b34e8b6ea711dbd in lucene-solr's branch refs/heads/branch_8x
from Chris M. Hostetter
[;h=371d645 ]

SOLR-12999: Harden TestReplicationHandlerDiskOverFlow against sporadic timing failures

 - ensure IndexFetcher injection is reset in @After method
 - replace System.out with Logger
 - Log and fail on any exceptions in any callbacks/threads
 - use CyclicBarrier (instead of CountdownLatch) to ensure the Query Thread loop doesn't monopolize
   CPU preventing IndexFetcher callback from ever being run

(Some of these improvements directly address jenkins failures we've been seeing)

(cherry picked from commit bf8c6ea435a39564d2a7de5c37cc9e522ca5b9cb)

> Index replication could delete segments first
> ---------------------------------------------
>                 Key: SOLR-12999
>                 URL:
>             Project: Solr
>          Issue Type: Improvement
>      Security Level: Public(Default Security Level. Issues are Public) 
>          Components: replication (java)
>            Reporter: David Smiley
>            Assignee: Noble Paul
>            Priority: Major
>             Fix For: 8.1
>         Attachments: SOLR-12999.patch, SOLR-12999.patch
> Index replication could optionally delete files that it knows will not be needed _first_.
 This would reduce disk capacity requirements of Solr, and it would reduce some disk fragmentation
when space get tight.
> Solr (IndexFetcher) already grabs the remote file list, and it could see which files
it has locally, then delete the others.  Today it asks Lucene to {{deleteUnusedFiles}} at
the end.  This new mode would probably only be useful if there is no SolrIndexSearcher open,
since it would prevent the removal of files.
> The motivating scenario is a SolrCloud replica that is going into full recovery.  It
ought to not be fielding searches.  The code changes would not depend on SolrCloud though.
> This option would have some danger the user should be aware of.  If the replication fails,
leaving the local files incomplete/corrupt, the only recourse is to try full replication again.
 You can't just give up and field queries.

This message was sent by Atlassian JIRA

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

View raw message