[
https://issues.apache.org/jira/browse/SOLR-5459?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erick Erickson updated SOLR-5459:
---------------------------------
Attachment: SOLR-5459.patch
Here's a quick hack at a patch that does this. It makes me quite nervous. It
looks remarkably like some of our test code, creating a temporary directory,
copying the conf directory over, and then trying to load it. If you navigate
away from the edit page, it loses any changes you've made.
It also takes a while longer, and will take even longer from ZooKeeper. Do we
really want to bring the conf directory down from ZK, test it, and throw it
away? Or is there a better way?
It has to clean up after itself by doing a FileUtils.deleteDirectory().
I've walked through it by hand and modified one of the local filesystem tests
to try it and it appears to work.
[~steffkes] The response returned will now have an error in it, but that's not
displayed. This is a marker, I'm not sure whether we want to go forward with
this or not. And if an error is returned the progress indicator on the save
button never stops.
[~markrmil...@gmail.com] is this anything like what you had in mind?
NOTE: I need to clean it up, but another instance of throwing something up
that's not ready to see what people think.
Still to do is the ZooKeeper version.
> Try loading a temporary core when saving a file in the admin UI config
> editing mode
> -----------------------------------------------------------------------------------
>
> Key: SOLR-5459
> URL: https://issues.apache.org/jira/browse/SOLR-5459
> Project: Solr
> Issue Type: Improvement
> Reporter: Erick Erickson
> Assignee: Erick Erickson
> Attachments: SOLR-5459.patch
>
>
> SOLR-5287 adds the ability to shoot yourself in the foot by changing core
> config files such that the core can't load, leading to having to go out into
> the filesystem and manually edit the files until you _can_ reload the core.
> This is clumsy at best.
> Mark Miller suggested creating a temporary core and trying to reload it
> before saving the "real" changes, which gives us an approach to the problem
> that seems relatively easy to implement.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
