Received ping response with no matching id

[nik9000]

I'm seeing a bunch of these on startup:

[2014-10-28 14:39:57,956][WARN ][discovery.zen.ping.multicast] [elastic1020] received ping response ping_response{target [[elastic1004][eq_H7EFGQ9SNTJuA6Wj9zw][elastic1004][inet[/10.64.0.111:9300]]{rack=A3, row=A, master=false}], master [[elastic1002][pEwiGcyESvSXFtUUwlh8qw][elastic1002][inet[/10.64.0.109:9300]]{rack=A3, row=A, master=true}], cluster_name[production-search-eqiad]} with no matching id [1]

and then everything works just fine. Is this OK?

[bleskes]

@nik9000 this can happen when a node takes more then 1.5 seconds to respond to a multicast ping - i.e., after the ping has been timed out locally. Nothing much to worry about if you had nodes under load (and you are indeed using multicast). It can also happen if you have restarted a node in the middle of pinging and it's very quick to come back. The node will receive answers to ping it's predecessor sent but of course, the id is no longer in memory.

Let me know if this explains things so we can close it (or not..).

[nik9000]

@bleskes thanks. That's certainly explains it. In this case the nodes aren't really under load.... Would a flood of nodes joining cause this? Like, if I added 10 nodes to my cluster really fast. Because I did.

[bleskes]

@nik9000 if you also took the nodes offline while other nodes were already pinging (for example, you had min master nodes breach) it does - the nodes got responses to the pings they sent before being restarted.

[nik9000]

I don't think that is what happened but I've suffered no ill effects from it. I'll just assume it was a blip of some sort.