Ignore:
Timestamp:
2019-08-08T15:15:11+12:00 (5 years ago)
Author:
ak19
Message:

Kathy found a problem whereby she wanted to run consecutive buildcols without activate on a solr collection. She experienced file locking issues on Windows, which the original solr related building code would inevitably cause without activate. Dr Bainbridge's solution was to change our way of thinking about what activate and buildcol should now be doing as regards solr collections. The solution was to unload building-cores for indexes at the end of buildcol, instead of only doing this during activate.pl. I've tried to be conservative with the changes made to the existing code, so that activate still attempts to also unload building-cores, but first pings them (and any other cores it attempts to unload) to ensure the cores exist. During buildcol too, the building-cores are pinged to check they exist before we attempt to unload them.

File:
1 edited

Legend:

Unmodified
Added
Removed
  • gs3-extensions/solr/trunk/src/perllib/solrserver.pm

    r33315 r33392  
    407407}
    408408
     409sub admin_unload_core_explicitly_retaining_index
     410{
     411    # For UNLOAD core params, see page 315 of
     412    #    https://archive.apache.org/dist/lucene/solr/ref-guide/apache-solr-ref-guide-4.7.pdf
     413   
     414    my $self = shift @_;
     415    my ($core) = @_;
     416   
     417    # Don't delete index (sidx/didx folder) along with unloading core, so force 0 as parameter
     418    # (though not deleting the index is the default behaviour of admin_unload_core() anyway,
     419    # since activate is meant to manually take care of deleting the index folder and moving the
     420    # building folder to replace index, instead of activate asking unload_core to delete the
     421    # index folder).
     422    # But this function's very particular behaviour may be crucial for other instances such as
     423    # its use in solrbuilder::post_build_indexes(), so even if admin_unload_core() could
     424    # conceivably be changed to delete the index by default, this method would still do the
     425    # right thing when called by solrbuilder::post_build_indexes().
     426    $self->admin_unload_core($core, 0);
     427}
     428
     429
    409430sub start
    410431{
Note: See TracChangeset for help on using the changeset viewer.