[
https://issues.apache.org/jira/browse/SOLR-11122?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erick Erickson updated SOLR-11122:
----------------------------------
Fix Version/s: 6.6.1
7.0
> Creating a core should write a core.properties file first and clean up on
> failure
> ---------------------------------------------------------------------------------
>
> Key: SOLR-11122
> URL: https://issues.apache.org/jira/browse/SOLR-11122
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: Erick Erickson
> Assignee: Erick Erickson
> Fix For: 7.0, 6.7, 6.6.1, master (8.0), 7.1
>
> Attachments: SOLR-11122.patch, SOLR-11122.patch
>
>
> I've made the handling of core.properties more consistent as part of the
> pluggable transient core work. However, a new inconsistency came to light.
> Most of the code assumes that a core.properties file exists, but it wasn't
> being persisted until the very end of the coreContainer.create process. So
> any steps part way through core creation that would manipulate the
> core.properties file wouldn't find it. And if those steps did make a mistake
> and call persist on the core.properties, create would fail because the
> core.properties file would be created. Worse, the transient cache handler had
> no way of knowing whether the core descriptors being added were from create
> (where the core.properties file hadn't been created yet) or
> reload/swap/rename. By moving persisting the core.properties earlier in the
> create process this would be less trappy.
> Any core.properties file created during this process will be removed if the
> create fails.
> Cores that are simply being _loaded_ on the other hand do _not_ have their
> core.properties files removed.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
