[
https://issues.apache.org/jira/browse/SOLR-4732?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shawn Heisey closed SOLR-4732.
------------------------------
Resolution: Invalid
Fix Version/s: (was: 4.3)
Assignee: Shawn Heisey
On IRC, Hoss wondered how this user was able to even get Solr working with this
solr.xml. It became clear when the user said that they have the following in
solrconfig.xml:
{noformat}
<dataDir>${MYSOLRROOT:/mysolrroot}/messages/solr/data/${solr.core.name}</dataDir>
{noformat}
On 3.5, when you rename or swap cores, the solr.core.name property does NOT get
updated until you restart Solr. I have no reason to think that 4.x is any
different, but I have not verified this.
> CoreAdmin - SWAP and RENAME with shared instanceDir and no dataDir - problems
> after Solr restart
> ------------------------------------------------------------------------------------------------
>
> Key: SOLR-4732
> URL: https://issues.apache.org/jira/browse/SOLR-4732
> Project: Solr
> Issue Type: Bug
> Affects Versions: 3.5
> Reporter: Shawn Heisey
> Assignee: Shawn Heisey
>
> If your cores share an instanceDir but dataDir is not explicitly defined in
> solr.xml, apparently dataDir is not "./data" as it would be when instanceDir
> is not shared, it becomes (or includes) the name of the core as well. This
> results in problems problems with RENAME, and probably SWAP as well.
> The RENAME will work, with the dataDir still retaining the old name. When
> you restart Solr, however, the core will use the new name for the dataDir and
> create an empty index, ignoring the old one. Based on this behavior, I
> believe that if you did a SWAP, after reload the cores would no longer be
> swapped.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]