How To Solve Issues Related to Log – Received response for a request that has timed out; sent ms ago; timed out ms ago; action ; node ; id

Prevent Your Next ELK Incident

Try our free Check Up to test if your ES issues are caused from misconfigured settings

Fix Issue

Updated: April-20

In-Page Navigation (click to jump) :

Opster Offer’s World-Class Elasticsearch Expertise In One Powerful Product
Try Our Free ES Check-Up   Prevent Incident

Overview: 

Elasticsearch search and index requests are executed within a timeout if specified, and if within the defined timeout threshold the request isn’t completed, then Elasticsearch sends the response calculated till that duration and in JSON response includes `timed_out: true`.

But the above time_out param in response is just an indicator that the request didn’t execute within a specified timeout, that it contained partial results and that the request is still  running in the background. When the request completes its execution, then Elasticsearch logs this as a *warning* in the log format below.

Received response for a request that has timed out, sent [{}ms] ago, timed out [{}ms] ago

If there are many such logs in a regular interval it should be fixed to prevent the outages and cluster resource saturations.

Some tips on how to identify the cause of such a timeout can be found in https://opster.com/elasticsearch-glossary/how-to-use-elasticsearch-slow-log-search-queries/, .This link is specific to search slow logs, but the same can be used to filter the slow indexing logs quickly as well. Most of the time, the cause of these timeouts is slow-running expensive search queries.

Once the cause of such timeout is identified below, fixes can be applied to prevent timeouts and to make clusters perform at an optimal level.

  1. Fix the expensive search queries by implementing them in different ways; One example is, Autocomplete queries which are expensive, and different implementation w.r.t to their performance impact as mentioned in https://opster.com/elasticsearch-glossary/elasticsearch-autocomplete-troubleshooting-guide/.
  2. If there is a huge number of documents in a single shard or fewer shards, then split them into additional shards on different physical servers and make the performance comparison between them. More info can be found here: https://opster.com/blogs/elasticsearch-shards-and-replicas-getting-started-guide/
  3. If you are using the latest Elasticsearch version(7.X) then use https://www.elastic.co/guide/en/elasticsearch/reference/current/tasks.html to identify the long-running tasks in Elaticsearch and kill them.
  4. Try including the timeout in more queries (with different values) and track the metrics (how many times they timeout) to get some idea of how they perform during peak times.
  5. For older versions of Elasticsearch like (1.X, 2.X) where task management API is not available, make use of terminate_after param in the search query to terminate long-running queries.

Insert same java code in opster page.

Troubleshooting background

To troubleshoot Elasticsearch log “Received response for a request that has timed out; sent ms ago; timed out ms ago; action ; node ; id” it’s important to understand common problems related to Elasticsearch concepts: node, request, response. See detailed explanations below complete with common problems, examples and useful tips.

Nodes in Elasticsearch

What it is

Simply explained a node is a single server that is part of a cluster. Each node is assigned with one or more roles, which describes the node responsibility and operations – Data nodes stores the data, and participates in the cluster’s indexing and search capabilities, while master nodes are responsible for managing the cluster activities and storing the cluster state, including the metadata.

While it’s possible to run several Node instances of Elasticsearch on the same hardware, it’s considered a best practice to limit a server to a single running instance of Elasticsearch.

Nodes connect to each other and form a cluster by using a discovery method. 

Roles
Master node

Master nodes are in charge of cluster-wide settings and changes  – deleting or creating indices and fields, adding or removing nodes and allocating shards to nodes. Each cluster has a single master node that is elected from the master eligible nodes using a distributed consensus algorithm and is reelected if the current master node fails.

Coordinator Node (aka client node)

Coordinator Node – is a node that does not hold any configured role. It doesn’t hold data, not part of the master eligible group nor execute ingest pipelines. Coordinator node serves incoming search requests and is acting as the query coordinator – running the query and fetch phases, sending requests to every node which holds a shard being queried. The client node also distributes bulk indexing operations and route queries to shards copies based on the nodes responsiveness.


To help troubleshoot related issues we have gathered selected Q&A from the community and issues from Github , please review the following for further information :

1 Es Cluster Fails At Random Times  

2Received Response For A Request Tha  


Log Context

Log ”Received response for a request that has timed out; sent [{}ms] ago; timed out [{}ms] ago; action [{}]; node [{}]; id [{}]” classname is TransportService.java
We have extracted the following from Elasticsearch source code to get an in-depth context :

             final String action;
            assert clientHandlers.get(requestId) == null;
            TimeoutInfoHolder timeoutInfoHolder = timeoutInfoHandlers.remove(requestId);
            if (timeoutInfoHolder != null) {
                long time = System.currentTimeMillis();
                logger.warn("Received response for a request that has timed out; sent [{}ms] ago; timed out [{}ms] ago; action [{}]; node [{}]; id [{}]"; time - timeoutInfoHolder.sentTime(); time - timeoutInfoHolder.timeoutTime(); timeoutInfoHolder.action(); timeoutInfoHolder.node(); requestId);
                action = timeoutInfoHolder.action();
                sourceNode = timeoutInfoHolder.node();
            } else {
                logger.warn("Transport response handler not found of id [{}]"; requestId);
                action = null;






About Opster

Opster identifies and predicts root causes of Elasticsearch problems, provides recommendations and can automatically perform various actions to prevent issues, optimize performance and save resources.

Learn more: Glossary | Blog| Troubleshooting guides | Error Repository

Need help with any Elasticsearch issue ? Contact Opster