lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hoss Man (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (SOLR-2691) solr.xml persistence is broken for multicore (by SOLR-2331)
Date Wed, 03 Aug 2011 02:42:27 GMT

     [ https://issues.apache.org/jira/browse/SOLR-2691?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Hoss Man updated SOLR-2691:
---------------------------

    Attachment: SOLR-2691.patch

patch of persistence tests at the CoreContainer level (since that's where the bug was)  that
incorporates Yury's fix.

the assertions could definitely be beefed up to sanity check more aspects of the serialization,
and we should really also be testing that "load" works and parses all of these things back
in in the expected way as well, but it's a start.

The thing that's currently hanging me up is that somehow the test is leaking a SolrIndexSearcher
reference.  I thought maybe it was because of the SolrCores i was creating+registering and
then ignoring, but if i try to close them i get an error about too many decrefs instead.

I'll let miller figure it out

> solr.xml persistence is broken for multicore (by SOLR-2331)
> -----------------------------------------------------------
>
>                 Key: SOLR-2691
>                 URL: https://issues.apache.org/jira/browse/SOLR-2691
>             Project: Solr
>          Issue Type: Bug
>          Components: multicore
>    Affects Versions: 4.0
>            Reporter: Yury Kats
>            Assignee: Mark Miller
>            Priority: Critical
>             Fix For: 4.0
>
>         Attachments: SOLR-2691.patch, jira2691.patch
>
>
> With the trunk build, running SolrCloud, if I issue a PERSIST CoreAdmin command,
> the solr.xml gets overwritten with only the last core, repeated as many times
> as there are cores.
> It used to work fine with a trunk build from a couple of months ago, so it looks like
> something broke solr.xml persistence. 
> It appears to have been introduced by SOLR-2331:
> CoreContainer#persistFile creates the map for core attributes (coreAttribs) outside 
> of the loop that iterates over cores. Therefore, all cores reuse the same map of attributes
> and hence only the values from the last core are preserved and used for all cores in
the list.
> I'm running SolrCloud, using:
> -Dbootstrap_confdir=/opt/solr/solr/conf -Dcollection.configName=hcpconf -DzkRun
> I'm starting Solr with four cores listed in solr.xml:
> <solr persistent="true">
>   <cores adminPath="/admin/cores" defaultCoreName="master1">
>     <core name="master1" instanceDir="master1" shard="shard1" collection="hcpconf"
/>
>     <core name="master2" instanceDir="master2" shard="shard2" collection="hcpconf"
/>
>     <core name="slave1" instanceDir="slave1" shard="shard1" collection="hcpconf" />
>     <core name="slave2" instanceDir="slave2" shard="shard2" collection="hcpconf" />
>   </cores>
> </solr>
> I then issue a PERSIST request:
> http://localhost:8983/solr/admin/cores?action=PERSIST
> And the solr.xml turns into:
> <solr persistent="true">
>   <cores defaultCoreName="master1" adminPath="/admin/cores" zkClientTimeout="10000"
hostPort="8983" hostContext="solr">
>     <core shard="shard2" instanceDir="slave2/" name="slave2" collection="hcpconf"/>
>     <core shard="shard2" instanceDir="slave2/" name="slave2" collection="hcpconf"/>
>     <core shard="shard2" instanceDir="slave2/" name="slave2" collection="hcpconf"/>
>     <core shard="shard2" instanceDir="slave2/" name="slave2" collection="hcpconf"/>
>   </cores>
> </solr>

--
This message is automatically generated by JIRA.
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


Mime
View raw message