Return-Path: X-Original-To: apmail-lucene-dev-archive@www.apache.org Delivered-To: apmail-lucene-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 0B78A990E for ; Wed, 7 Mar 2012 18:53:31 +0000 (UTC) Received: (qmail 86034 invoked by uid 500); 7 Mar 2012 18:53:29 -0000 Delivered-To: apmail-lucene-dev-archive@lucene.apache.org Received: (qmail 85710 invoked by uid 500); 7 Mar 2012 18:53:28 -0000 Mailing-List: contact dev-help@lucene.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@lucene.apache.org Delivered-To: mailing list dev@lucene.apache.org Received: (qmail 85530 invoked by uid 99); 7 Mar 2012 18:53:23 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 07 Mar 2012 18:53:23 +0000 X-ASF-Spam-Status: No, hits=-2000.0 required=5.0 tests=ALL_TRUSTED,T_RP_MATCHES_RCVD X-Spam-Check-By: apache.org Received: from [140.211.11.116] (HELO hel.zones.apache.org) (140.211.11.116) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 07 Mar 2012 18:53:20 +0000 Received: from hel.zones.apache.org (hel.zones.apache.org [140.211.11.116]) by hel.zones.apache.org (Postfix) with ESMTP id 20017E55E for ; Wed, 7 Mar 2012 18:52:59 +0000 (UTC) Date: Wed, 7 Mar 2012 18:52:59 +0000 (UTC) From: "Erick Erickson (Commented) (JIRA)" To: dev@lucene.apache.org Message-ID: <1716201684.35357.1331146379132.JavaMail.tomcat@hel.zones.apache.org> In-Reply-To: <682477745.4186.1330544037066.JavaMail.tomcat@hel.zones.apache.org> Subject: [jira] [Commented] (SOLR-3182) If there is only one core, let it be the default without specifying a default in solr.xml MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 X-Virus-Checked: Checked by ClamAV on apache.org [ https://issues.apache.org/jira/browse/SOLR-3182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13224584#comment-13224584 ] Erick Erickson commented on SOLR-3182: -------------------------------------- Do we want to carry this forward for 3.x? If so, we need to get consensus real soon now since there's a movement to cut a 3.6 (the last 3x release planned?) in 10 days or so. I've assigned it to myself just as a placeholder, if someone else wants to go ahead and take this, please feel free. Or does all the SolrCloud stuff make this something we don't want to deal with (in which case there never will be a 3.x way to handle this)... Or does it make sense to do this for 3.6 and not try to move it into trunk? > If there is only one core, let it be the default without specifying a default in solr.xml > ----------------------------------------------------------------------------------------- > > Key: SOLR-3182 > URL: https://issues.apache.org/jira/browse/SOLR-3182 > 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/CoreContainer.java > =================================================================== > --- solr/core/src/java/org/apache/solr/core/CoreContainer.java (revision 1295229) > +++ solr/core/src/java/org/apache/solr/core/CoreContainer.java (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: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org For additional commands, e-mail: dev-help@lucene.apache.org