<p dir="auto">As-is, the repository-hdfs plugin isn't going to work at all from what i see.</p>
<p dir="auto">I'm just plotting what I think we need to do to fix it, before releasing it:</p>
<ul dir="auto">
<li>Four plugin zip versions are created, none are really tested, none are working (except on windows). For example the <code class="notranslate">-lite.zip</code> has no hadoop jars and expects the users to drop hadoop jars in their ES_CLASSPATH. We don't allow this, this is not going to work at all.</li>
<li>we need to drop the <code class="notranslate">-hadoop1</code> and <code class="notranslate">-lite</code> stuff and just one have one jar, we need to get the basics working, walk before we can run. from what i see, things aren't working at all.</li>
<li>documentation recommends adding configuration files and similar to the <code class="notranslate">CLASSPATH</code> or ES <code class="notranslate">lib/</code> folder, we can't do things this way anymore! Its not going to work!</li>
<li>security permissions are not correct: it only adds <code class="notranslate">jaas_nt</code>. This means that this plugin is only going to work on windows NT platforms: anything else = instant security exception.</li>
<li>The use of HDFS should be made reliable (means hdfs2 only), since its a snapshot restore plugin. To me this means two things, fsync and atomic rename. I don't see any synchronization, and the rename it uses for committing does not look like the atomic one (rename2).</li>
<li>no tests are failing!</li>
</ul>
<p dir="auto"><strong>Elasticsearch version</strong>: 5.0.0-alpha3</p>
<p dir="auto"><strong>JVM version</strong>: 1.8.0_73-b02</p>
<p dir="auto"><strong>OS version</strong>: CentOS Linux release 7.2.1511</p>
<p dir="auto"><strong>Description of the problem including expected versus actual behavior</strong>:<br>
I'm trying to upgrade an ES plugin from 2.3 to 5.0.0-alpha3, and a template we previously had working is now causing an issue. The template attempts to set some default analyzers for an index, but when the index is created it throws an error saying there's already an analyzer with the default name.</p>
<p dir="auto">Here's the template I'm using:<br>
<code class="notranslate">{ "order": 0,  "settings": { "index.analysis.analyzer.fairhairIndexAnalyzerv3.alias": "default", "index.analysis.analyzer.fairhairIndexAnalyzerv3.type": "fairhair-index-analyzer", "index.analysis.analyzer.fairhairTokenizingAnalyzer.type": "fairhair-tokenizing-analyzer", "index.analysis.analyzer.fairhairTokenizingAnalyzer.alias": "default_search" }, "mappings" : { //some mappings }, "template" : "document.*" }</code></p>
<p dir="auto"><strong>Provide logs (if relevant)</strong>:<br>
Here's the error stack trace I get:<br>
<code class="notranslate">elasticsearch_1  | [2016-06-28 23:40:43,871][DEBUG][action.admin.indices.create] [Iridia] [document.document-20151106] failed to create elasticsearch_1  | java.lang.IllegalStateException: already registered analyzer with name: default elasticsearch_1  |  at org.elasticsearch.index.analysis.AnalysisService.&lt;init&gt;(AnalysisService.java:109) elasticsearch_1  |  at org.elasticsearch.index.analysis.AnalysisRegistry.build(AnalysisRegistry.java:161) elasticsearch_1  |  at org.elasticsearch.index.IndexService.&lt;init&gt;(IndexService.java:138) elasticsearch_1  |  at org.elasticsearch.index.IndexModule.newIndexService(IndexModule.java:328) elasticsearch_1  |  at org.elasticsearch.indices.IndicesService.createIndexService(IndicesService.java:398) elasticsearch_1  |  at org.elasticsearch.indices.IndicesService.createIndex(IndicesService.java:363) </code></p>
<p dir="auto">I've looked at the AnalysisService class constructor, and I see it does a check for analyzers with the name "default" in the passed in analyzer mappings. I believe these conditional statements fire:</p>
<p dir="auto"><code class="notranslate">if (!analyzerProviders.containsKey("default")) { analyzerProviders.put("default", new StandardAnalyzerProvider(indexSettings, null, "default", Settings.Builder.EMPTY_SETTINGS)); } if (!analyzerProviders.containsKey("default_search")) { analyzerProviders.put("default_search", analyzerProviders.get("default")); } if (!analyzerProviders.containsKey("default_search_quoted")) { analyzerProviders.put("default_search_quoted", analyzerProviders.get("default_search")); }</code></p>
<p dir="auto">So it registers the standard analyzer, but while iterating through the passed in analyzers, this check also fires:</p>
<p dir="auto"><code class="notranslate">if (analyzers.containsKey(name)) { //Grabs the name from each entry in analyzer map throw new IllegalStateException("already registered analyzer with name: " + name); }</code></p>
<p dir="auto">I'm confused as to how both these conditions are firing. This check to see if the current map of analyzers already contains the key "name" was introduced in ES 5.</p>
<p dir="auto">EDIT: I know why the illegal state exception is being thrown. The Analysis Registry automatically adds the entry: "default" =&gt; StandardAnalyzer. So from what I can tell, it's actually impossible to register your own default index analyzer, since there will always be the standard analyzer. I think the check for whether a name is already in the analyzer mappings is a bug and should be removed.</p>