lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF subversion and git services (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (SOLR-11122) Creating a core should write a core.properties file first and clean up on failure
Date Wed, 16 Aug 2017 21:25:00 GMT

    [ https://issues.apache.org/jira/browse/SOLR-11122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16129444#comment-16129444
] 

ASF subversion and git services commented on SOLR-11122:
--------------------------------------------------------

Commit ea427f1ac5014d593712a62113add43fe1e28cbb in lucene-solr's branch refs/heads/branch_6_6
from Erick
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=ea427f1 ]

SOLR-11122: Creating a core should write a core.properties file first and clean up on failure

(cherry picked from commit 4041f8a1c97d9703b5d38b65e842e57cb359da64)


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


Mime
View raw message