I looked at the lucee 4.5 source code, and found it is not designed to ignore the error. The master branch of Lucee 5 doesn't have this fix either. The master branch of lucee is currently at Lucee 5.2.9 which is the highest release quality version of Lucee.

What you are waiting for seems to be a quick fix to that master branch so that you don't have to incur the risk of the 5.3 branch which this problem appears to have been fixed already in October. There are a lot of bugs during that time in 5.3 actively being looked at, that make it hard to use any version but the newest snapshots. The snapshots are available in the lucee admin, and they usually work ok, but some of the admin changes have been annoying, less of a problem if you are not using lucee exclusive features.

5.2:
https://github.com/lucee/Lucee/blob/master/core/src/main/java/lucee/runtime/config/XMLConfigWebFactory.java

5.3:
https://github.com/lucee/Lucee/blob/5.3/core/src/main/java/lucee/runtime/config/XMLConfigWebFactory.java

The log object is not being passed to the function on lucee 5.2, so it can't run the same code, so you'd have to implement a lot more changes :
try {
// loadxml
catch (Exception e) {
log(config, log, e);
}
I looked at the commit history, and he has this massive commit of over 400 changes required to get logs centralized.
https://github.com/lucee/Lucee/commit/9eda810c5a87a10707ff2e5f5895ead5cdae7256#diff-7d71424455db44db33dd5c5ce06d5315

and then a few months later, he came up with this commit which fixes your problem by making a lot of those things optional to startup when they fail:
https://github.com/lucee/Lucee/commit/0ed3937f7b22fe9112b56e1430fd1b07656a58fa#diff-7d71424455db44db33dd5c5ce06d5315

It looks like a lot to ask to pull all those changes into the stable 5.2 branch.

If you really want to quick fix your problem without using 5.3 (corrected), you'd have to modify loadSearch in that file to just silently fail or do some custom log to keep it simple. It could be weeks or months until 5.3 is officially release quality and stable. I run 5.3.2.16-snapshot in production, and other then the bugs I reported, it is better then any other lucee release.

Of course any number of other issues could effect you if you choose to run the latest snapshot, so do so at your own risk. I would definitely use a test environment first.

@Patrick Quinn @Michael Offner @Pothys - MitrahSoft - This is still happening and it has just happened two days in a row, which isn't good for our client. Any chance someone can take a look? If it is something you think might be different in 5.x as the search engine has been moved out into an extension as maybe updated (????) then let me know as it might be possible to update the server from 4.5.x to 5.x.

Thanks again for the update, Andrew. Still on my watch list, so I'll be sure to keep an eye on it, priority-wise, as we wrap up the development year, and as we're planning the 2018 development schedule. Stay tuned.

@Patrick Quinn - We have just had this again and this time it wasn't associated with a Tomcat restart, if it becomes corrupt at any time it causes the whole site to become unavailable. If you then go into the directory and delete the search.xml the site starts functioning again, without having to restart Tomcat. This time the corruption coincided with an update of the search index, so I assume it is the search index process corrupting the file. I think on the previous occurrences when we saw this, it was probably already an issue before the Tomcat restart, it is just we noticed after the restart as we checked some sites. We now have monitoring on this specific site, hence noticing when Tomcat had not been restarted. I've updated the description to reflect this.

Thanks for these updates, @Andrew Dixon. That should help us as we work on this one.