[ 
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-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Reply via email to