Closed redlus closed 6 years ago
"type": "illegal_argument_exception", "reason": "persistent setting [search.remote.tier-1.initial_connect_timeout], not recognized"
The problem here is that there is no per remote-cluster setting called intial_connect_timeout
. You will get a similar error message if you try to add such a setting to the configuration file:
Caused by: java.lang.IllegalArgumentException: unknown setting [search.remote.tier-1.initial_connect_timeout] did you mean [search.remote.initial_connect_timeout]?
at org.elasticsearch.common.settings.AbstractScopedSettings.validate(AbstractScopedSettings.java:344) ~[elasticsearch-7.0.0-alpha1-SNAPSHOT.jar:7.0.0-alpha1-SNAPSHOT]
at org.elasticsearch.common.settings.AbstractScopedSettings.validate(AbstractScopedSettings.java:308) ~[elasticsearch-7.0.0-alpha1-SNAPSHOT.jar:7.0.0-alpha1-SNAPSHOT]
at org.elasticsearch.common.settings.AbstractScopedSettings.validate(AbstractScopedSettings.java:282) ~[elasticsearch-7.0.0-alpha1-SNAPSHOT.jar:7.0.0-alpha1-SNAPSHOT]
at org.elasticsearch.common.settings.SettingsModule.<init>(SettingsModule.java:135) ~[elasticsearch-7.0.0-alpha1-SNAPSHOT.jar:7.0.0-alpha1-SNAPSHOT]
at org.elasticsearch.node.Node.<init>(Node.java:339) ~[elasticsearch-7.0.0-alpha1-SNAPSHOT.jar:7.0.0-alpha1-SNAPSHOT]
at org.elasticsearch.node.Node.<init>(Node.java:252) ~[elasticsearch-7.0.0-alpha1-SNAPSHOT.jar:7.0.0-alpha1-SNAPSHOT]
at org.elasticsearch.bootstrap.Bootstrap$5.<init>(Bootstrap.java:212) ~[elasticsearch-7.0.0-alpha1-SNAPSHOT.jar:7.0.0-alpha1-SNAPSHOT]
at org.elasticsearch.bootstrap.Bootstrap.setup(Bootstrap.java:212) ~[elasticsearch-7.0.0-alpha1-SNAPSHOT.jar:7.0.0-alpha1-SNAPSHOT]
at org.elasticsearch.bootstrap.Bootstrap.init(Bootstrap.java:323) ~[elasticsearch-7.0.0-alpha1-SNAPSHOT.jar:7.0.0-alpha1-SNAPSHOT]
at org.elasticsearch.bootstrap.Elasticsearch.init(Elasticsearch.java:136) ~[elasticsearch-7.0.0-alpha1-SNAPSHOT.jar:7.0.0-alpha1-SNAPSHOT]
... 6 more
If you think the docs are not clear on this point, we are open to the feedback, yet contrast the documentation for search.remote.initial_connect_timeout
versus search.remote.${cluster_alias}.skip_unavailable
with the latter indicating that it is a per remote-cluster setting.
Do note that this setting is indeed not dynamic however I think it is fine as a static setting, given that it is not per remote-cluster.
Eat your popcorn and enjoy the error message.
Comments like this are unhelpful and unnecessary.
@jasontedor
I've only written the requests and response when inserting the setting at the cluster level, but this happens on every level. E.g. on 'search.remote' level:
{ "persistent": { "search": { "remote": { "tier-2": { "seeds": "192.168.0.47:9300" }, "tier-1": { "seeds": "192.168.0.45:9300" }, "initial_connect_timeout": "60s" } } } }
Response:
{ "error": { "root_cause": [ { "type": "remote_transport_exception", "reason": "[elasticmaster1][192.168.0.42:9300][cluster:admin/settings/update]" } ], "type": "illegal_argument_exception", "reason": "persistent setting [search.remote.initial_connect_timeout], not dynamically updateable" }, "status": 400 }
On 'search' level:
{ "persistent": { "search": { "remote": { "tier-2": { "seeds": "192.168.0.47:9300" }, "tier-1": { "seeds": "192.168.0.45:9300" } }, "initial_connect_timeout": "60s" } } }
Response:
{ "error": { "root_cause": [ { "type": "remote_transport_exception", "reason": "[elasticmaster1][192.168.0.42:9300][cluster:admin/settings/update]" } ], "type": "illegal_argument_exception", "reason": "persistent setting [search.initial_connect_timeout], not recognized" }, "status": 400 }
As I said:
Do note that this setting is indeed not dynamic however I think it is fine as a static setting, given that it is not per remote-cluster.
You have to set this statically in the configuration file.
@jasontedor I felt the emphasis was needed after your reference of what is and what is not a per-cluster setting:
contrast the documentation for search.remote.initial_connect_timeout versus search.remote.${cluster_alias}.skip_unavailable with the latter indicating that it is a per remote-cluster setting.
In any case, stating all these settings in one section without noting which is static and which is not is confusing IMHO (especially given that the cluster setting API is mentioned as an alternative to the elasticsearch.yml option) -
The equivalent example using the cluster settings API to add remote clusters to all nodes in the cluster would look like the following
More importantly, I hold the belief that almost any setting which can become dynamic should definitely have this option. Too many times we find outselves needing to perform a rolling restart of large elasticsearch clusters just to activate a feature or fine-tune one that has already been activated using a rolling-restart. This time I'm referring to this issue (and setting) - #30687.
Hi,
Elasticsearch version 6.2.3
Plugins installed ingest-attachment ingest-geoip mapper-murmur3 mapper-size repository-azure repository-gcs repository-s3
JVM version openjdk version "1.8.0_151" OpenJDK Runtime Environment (build 1.8.0_151-8u151-b12-0ubuntu0.16.04.2-b12) OpenJDK 64-Bit Server VM (build 25.151-b12, mixed mode) OS version (
uname -a
if on a Unix-like system):Description of the problem including expected versus actual behavior We're using the cross-cluster search to make searches across several clusters. The settings are pushed using PUT to _cluster/settings on the live clusters. When acknowledged, the remote clusters get the default settings as views in _remote/info.
Trying to change these settings through the same API raises errors; for example, calling:
{ "persistent": { "search": { "remote": { "tier-2": { "seeds": "192.168.0.47:9300", "initial_connect_timeout": "60s" }, "tier-1": { "seeds": "192.168.0.45:9300", "initial_connect_timeout": "60s" } } } } }
returns this:
{ "error": { "root_cause": [ { "type": "remote_transport_exception", "reason": "[elasticmaster1][192.168.0.42:9300][cluster:admin/settings/update]" } ], "type": "illegal_argument_exception", "reason": "persistent setting [search.remote.tier-1.initial_connect_timeout], not recognized" }, "status": 400 }
If these settings should be changed only in elasticsearch.yml, it should be stated so in the documentation. However, given that new remote clusters can be set on the fly, I see not reason to support different settings only though one option and not the other.
Steps to reproduce
Provide logs (if relevant) The master node presents the following log message: