You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Elasticsearch version (bin/elasticsearch --version):
Plugins installed: [my custom similarity plugin]
JVM version (java -version): 1.8.0_111-b14
OS version (uname -a if on a Unix-like system): Windows 10
Description of the problem including expected versus actual behavior:
Elasticsearch will not start when there are existing indexes with a custom similarity.
The exception is: Error injecting constructor, java.lang.IllegalStateException: unable to upgrade the mappings for the index [[boe_pc/PGTTzoK3SV-A54eryi40iw]],
which is caused by:
java.lang.IllegalArgumentException: Unknown Similarity type [bounded_similarity] for [default]
Bounded_similarity is the name of my custom similarity.
To me it looks like Elasticsearch starts upgrading the existing indexes before calling the plugins "onIndexModule". When starting a cluster with no data and creating a simple index, "onIndexModule" gets called, but when ES starts with existing indexes, it crashes in the upgrade procedure without calling my plugin.,
I think in general it would be handy when there is an option to allow an index with a problematic custom similarity to be loaded anyway (without that similarity). If that is the case, one can manipulate the index definition afterwards.
I can work around it: I can simply copy the documents from the old index to a brand new index in the new cluster. But it is a pain, and it is not the first time that upgrades fail because of this...
Steps to reproduce:
Please include a minimal but complete recreation of the problem, including
(e.g.) index creation, mappings, settings, query etc. The easier you make for
us to reproduce it, the more likely that somebody will take the time to look at it.
Create an index with a custom similarity in a 5.4.0 cluster
Upgrade the cluster to 5.6.0
I can provide my 5.4 and 5.6 plugin and an index definition if you wish.
Provide logs (if relevant):
I can provide logs if you wish.
The text was updated successfully, but these errors were encountered:
Describe the feature:
Elasticsearch version (
bin/elasticsearch --version
):Plugins installed: [my custom similarity plugin]
JVM version (
java -version
): 1.8.0_111-b14OS version (
uname -a
if on a Unix-like system): Windows 10Description of the problem including expected versus actual behavior:
Elasticsearch will not start when there are existing indexes with a custom similarity.
The exception is: Error injecting constructor, java.lang.IllegalStateException: unable to upgrade the mappings for the index [[boe_pc/PGTTzoK3SV-A54eryi40iw]],
which is caused by:
java.lang.IllegalArgumentException: Unknown Similarity type [bounded_similarity] for [default]
Bounded_similarity is the name of my custom similarity.
To me it looks like Elasticsearch starts upgrading the existing indexes before calling the plugins "onIndexModule". When starting a cluster with no data and creating a simple index, "onIndexModule" gets called, but when ES starts with existing indexes, it crashes in the upgrade procedure without calling my plugin.,
I think in general it would be handy when there is an option to allow an index with a problematic custom similarity to be loaded anyway (without that similarity). If that is the case, one can manipulate the index definition afterwards.
I can work around it: I can simply copy the documents from the old index to a brand new index in the new cluster. But it is a pain, and it is not the first time that upgrades fail because of this...
Steps to reproduce:
Please include a minimal but complete recreation of the problem, including
(e.g.) index creation, mappings, settings, query etc. The easier you make for
us to reproduce it, the more likely that somebody will take the time to look at it.
I can provide my 5.4 and 5.6 plugin and an index definition if you wish.
Provide logs (if relevant):
I can provide logs if you wish.
The text was updated successfully, but these errors were encountered: