We add field mappings to our document types upon new index creation and it works well.
However, we see odd attempts to re-add the analyzer mappings at the startup time of our services that instantiate no-data elastic search nodes. There is nothing in our startup sequence that send off these mappings that we can see. It just looks like it is re-adding the mappings (or at least some of them), and it fails. For example from our logs at startup time:
19:55:53,388 WARN [elasticsearch[Scrambler]clusterService#updateTask-pool-7-thread-1] [indices.cluster] - [Scrambler] [index0] failed to add mapping [mail], source [org.elasticsearch.common.compress.CompressedString@bb75f1ce]
org.elasticsearch.index.mapper.MapperParsingException: Analyzer [kihaSnowball] not found for field [to]
We've started seeing this after startup time as well.
Again, all is working fine, and when we check the mappings, they are happy. We just see these concerning errors in the logs.
I am guessing this is because the analyzer is not defined in the non data
nodes settings as well. In 0.12, the high level indexes were created on all
nodes (each high level index can have zero or more shards allocated), and
some data is associated with it, for example, parsed mappings, analyzers and
so on.
As part of the effort to improve cases where many indices are created, in
master (0.13) there as been quite a big refactoring, causing those high
level index constructs to be created only if a shard is allocated on that
node. Of course, for non data nodes, this will never happen, so you won't
need to define these analyzers on the node itself.
We add field mappings to our document types upon new index creation and it
works well.
However, we see odd attempts to re-add the analyzer mappings at the startup
time of our services that instantiate no-data Elasticsearch nodes. There
is nothing in our startup sequence that send off these mappings that we can
see. It just looks like it is re-adding the mappings (or at least some of
them), and it fails. For example from our logs at startup time:
19:55:53,388 WARN
[elasticsearch[Scrambler]clusterService#updateTask-pool-7-thread-1]
[indices.cluster] - [Scrambler] [index0] failed to add mapping [mail],
source [org.elasticsearch.common.compress.CompressedString@bb75f1ce]
org.elasticsearch.index.mapper.MapperParsingException: Analyzer
[kihaSnowball] not found for field [to]
We've started seeing this after startup time as well.
Again, all is working fine, and when we check the mappings, they are happy.
We just see these concerning errors in the logs.
I am guessing this is because the analyzer is not defined in the non data
nodes settings as well. In 0.12, the high level indexes were created on all
nodes (each high level index can have zero or more shards allocated), and
some data is associated with it, for example, parsed mappings, analyzers and
so on.
As part of the effort to improve cases where many indices are created, in
master (0.13) there as been quite a big refactoring, causing those high
level index constructs to be created only if a shard is allocated on that
node. Of course, for non data nodes, this will never happen, so you won't
need to define these analyzers on the node itself.
We add field mappings to our document types upon new index creation and it
works well.
However, we see odd attempts to re-add the analyzer mappings at the
startup
time of our services that instantiate no-data Elasticsearch nodes. There
is nothing in our startup sequence that send off these mappings that we
can
see. It just looks like it is re-adding the mappings (or at least some of
them), and it fails. For example from our logs at startup time:
19:55:53,388 WARN
[elasticsearch[Scrambler]clusterService#updateTask-pool-7-thread-1]
[indices.cluster] - [Scrambler] [index0] failed to add mapping [mail],
source [org.elasticsearch.common.compress.CompressedString@bb75f1ce]
org.elasticsearch.index.mapper.MapperParsingException: Analyzer
[kihaSnowball] not found for field [to]
We've started seeing this after startup time as well.
Again, all is working fine, and when we check the mappings, they are
happy.
We just see these concerning errors in the logs.
Apache, Apache Lucene, Apache Hadoop, Hadoop, HDFS and the yellow elephant
logo are trademarks of the
Apache Software Foundation
in the United States and/or other countries.
