lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Russell Black (Commented) (JIRA)" <>
Subject [jira] [Commented] (SOLR-3182) If there is only one core, let it be the default without specifying a default in solr.xml
Date Sat, 03 Mar 2012 01:15:57 GMT


Russell Black commented on SOLR-3182:

Jan, that is an interesting idea and is similar to the one Yonik proposed earlier.  I am happy
with your proposal as it would address our situation just fine.  

That said, you could experience a type of inconsistent behavior with a $1 solution as well.
 Let's say I have two cores and have {{defaultCoreName=$1}}.  Then the first core gets deleted.
 Anyone who was making requests to the default core(/solr/select) will suddenly find that
they are getting different data because they are hitting a new core.  From this perspective,
the "magic" behavior would seem to be no worse than the inconsistency with the $1 solution.
 It's possible I am missing something here.  

As far as backwards compatibility, old solr.xmls will continue to operate as they always have,
the only difference being that single cores will be available via an additional url.  That
is, single cores will continue to be accessible by their name.  

I am willing to build the patch for whatever solution the committers agree on. 
> If there is only one core, let it be the default without specifying a default in solr.xml
> -----------------------------------------------------------------------------------------
>                 Key: SOLR-3182
>                 URL:
>             Project: Solr
>          Issue Type: Improvement
>          Components: multicore
>    Affects Versions: 3.6, 4.0
>            Reporter: Russell Black
>            Priority: Minor
>              Labels: patch
>         Attachments: SOLR-3182-default-core.patch
>   Original Estimate: 10m
>  Remaining Estimate: 10m
> Our particular need for this is as follows.  We operate in a sharded environment with
one core per server.  Each shard also acts as a collator.  We want to use a hardware load
balancer to choose which shard will do the collation for each query.  But in order to do that,
each server's single core would have to carry the same name so that it could be accessed by
the same url across servers.  However we name the cores by their shard number (query0,query1,...)
because it parallels with the way we name our indexing/master cores (index0, index1,...).
 This naming convention also gives us the flexibility of moving to a multicore environment
in the future without having to rename the cores, although admittedly that would complicate
load balancing.  
> In a system with a large number of shards and the anticipation of adding more going forward,
setting a defaultCoreName attribute in each solr.xml file becomes inconvenient, especially
since there is no Solr admin API for setting defaultCoreName.  It would have to be done by
hand or with some automated tool we would write in house.  Even if there were an API, logically
it seems unnecessary to have to declare the only core to be the default. 
> Fortunately this behavior can be implemented with the following simple patch:
> {code}
> Index: solr/core/src/java/org/apache/solr/core/
> ===================================================================
> --- solr/core/src/java/org/apache/solr/core/	(revision 1295229)
> +++ solr/core/src/java/org/apache/solr/core/	(working copy)
> @@ -870,6 +870,10 @@
>    }
>    private String checkDefault(String name) {
> +    // if there is only one core, let it be the default without specifying a default
in solr.xml
> +    if (defaultCoreName.trim().length() == 0 && name.trim().length() == 0 &&
cores.size() == 1) {
> +      return cores.values().iterator().next().getName();
> +    }
>      return name.length() == 0  || defaultCoreName.equals(name) || name.trim().length()
== 0 ? "" : name;
>    } 
> {code}

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:!default.jspa
For more information on JIRA, see:


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

View raw message