Transport response handler not found of

Elastic Stack Elasticsearch
1

I have two server, both with logstash 2.4.0 and elasticsearch 2.4.0. I found the following warnings in the elasticsearch log on my master node:

[2016-10-12 14:34:33,957][INFO ][cluster.metadata         ] [node-2] [filebeat-test-2016.10.12] creating index, cause [auto(bulk api)], templates [], shards [5]/[1], mappings []
[2016-10-12 14:34:34,234][INFO ][cluster.routing.allocation] [node-2] Cluster health status changed from [RED] to [YELLOW] (reason: [shards started [[filebeat-test-2016.10.12][3], [filebeat-test-2016.10.12][1], [filebeat-test-2016.10.12][4], [filebeat-test-2016.10.12][0], [filebeat-test-2016.10.12][2]] ...]).
[2016-10-12 14:34:34,620][INFO ][cluster.metadata         ] [node-2] [filebeat-test-2016.10.12] create_mapping [filebeat-test]
[2016-10-12 14:34:35,520][INFO ][cluster.routing.allocation] [node-2] Cluster health status changed from [YELLOW] to [GREEN] (reason: [shards started [[filebeat-test-2016.10.12][4]] ...]).

On my data node I can see nearly at the same time:

    [2016-10-12 14:34:34,485][WARN ][transport                ] [node-1] Transport response handler not found of id [877575]
    [2016-10-12 14:34:34,495][WARN ][transport                ] [node-1] Transport response handler not found of id [877576]
    [2016-10-12 14:34:35,195][WARN ][transport                ] [node-1] Transport response handler not found of id [877599]

Can someone explain, what happened here?

2

This might be a known issue in 2.4.0 that according to Don't send exception responses twice by imotov · Pull Request #20585 · elastic/elasticsearch · GitHub should be fixed in 2.4.1. Can you try and test with that version?

3

After update, no log entries on the data node, but no change on the master node:

[2016-10-12 15:49:53,324][INFO ][cluster.metadata         ] [node-2] [filebeat-test-2016.10.12] creating index, cause [auto(bulk api)], templates [], shards [5]/[1], mappings []
[2016-10-12 15:49:53,565][INFO ][cluster.routing.allocation] [node-2] Cluster health status changed from [RED] to [YELLOW] (reason: [shards started [[filebeat-test-2016.10.12][2], [filebeat-test-2016.10.12][0], [filebeat-test-2016.10.12][4], [filebeat-test-2016.10.12][1], [filebeat-test-2016.10.12][3]] ...]).
[2016-10-12 15:49:54,073][INFO ][cluster.metadata         ] [node-2] [filebeat-test-2016.10.12] create_mapping [filebeat-test]
[2016-10-12 15:49:54,263][INFO ][cluster.routing.allocation] [node-2] Cluster health status changed from [YELLOW] to [GREEN] (reason: [shards started [[filebeat-test-2016.10.12][3], [filebeat-test-2016.10.12][1]] ...]).
4

That looks normal though, see - for example - this explanation about the cluster health status.

5

These log lines are informing you (hence logging level INFO) that a new index has been created. It's not a warning. Nothing to worry about.

6

Oh thanks, I was confused, because the cluster state was red and I associated red=error :slight_smile:

7

Index creation makes the cluster red for a very short moment (until shards are started and ready for indexing). In v5.0.0 we have changed this to make it more user-friendly (see here: https://github.com/elastic/elasticsearch/pull/19450 ).

1 Like