Why "I/O Reactor STOPPED" Is Reported When I Use the Elasticsearch HLRC?

Symptom

When I use the HLRC (High Level Rest Client) of Elasticsearch, "I/O Reactor STOPPED" is occasionally reported, but no errors are found in Elasticsearch logs.

Checking Why the I/O Reactor Status Changed to STOPPED

In the call stack, the error is found in line 90 in CloseableHttpAsyncClientBase, as shown in the following figure.

The ensureRunning() method is called at the beginning of request execution to check whether the client is active. If the client is inactive, an error will be reported. Check when the status in CloseableHttpAsyncClientBase changed to STOPPED. Two occurrences are found, as shown in the following figures.

Figure 1 First occurrence of STOPPED

Figure 2 Second occurrence of STOPPED

• It can be inferred that only the first occurrence made the status change to STOPPED, because generally a user would not close the client before calling an API.
• In the first occurrence, the reactorThread thread scheduled schedule I/O events. The status changed to STOPPED when an internal exception is thrown. To reproduce this issue, throw an exception and check whether the status will change, as shown in the following figure.

  

• When a request fails because of the exception, the status changes to STOPPED, the I/O Reactor is disabled, and the HLRC instance is suspended. Then, the HLRC instance fails at any attempt to call a request. Here the exception was manually created to reproduce the issue, but the cause of the I/O Reactor exception in the production environment is still unknown.

Possible Causes

The possible causes of the I/O Reactor exception are as follows:

1. Exception thrown during callback
2. High client concurrency

   After the exception was found in the customer's logs, we checked the Elasticsearch cluster monitoring metrics, including the CPU usage and number of network connections.

   The customer's cluster used five i3.4xlarge.8 nodes with 16 vCPUs and 128 GB memory. The customer performed a large number of bulk operations at around 05:00 every morning and wrote 100 GB to 200 GB data. Cluster monitoring metrics showed that the CPU usage and network inbound and outbound rates did not bring heavy workloads to nodes, but the number of network connections on each node was large. The network connections on certain nodes nearly reached 9,000, and even 50,000 on five nodes. The code used multiple threads of a single REST client to concurrently invoke the bulkAsync interface of the HLRC. The 40,000 to 50,000 Elasticsearch connections on a single client node could easily exhaust handles or connections of the node.

3. REST client of Elasticsearch. You are advised to add the exception handler to the REST client of Elasticsearch.

   Both HLRC and LLRC use Apache HTTPComponents Async Client. As mentioned in the documentation of Apache, some I/O exceptions during the interaction with sessions are predictable. Such exceptions may cause the termination of a single session, but do not affect I/O Reactor or other sessions. However, if an error occurs in I/O Reactor, such as the I/O exceptions in some classes of the underlying NIO or runtime exceptions that have not been not handled, I/O Reactor will shut down. Apache recommends that the IOReactorExceptionHandler interface be rewritten.

   Figure 3 Rewriting the IOReactorExceptionHandler API
   

   We rewrote the ExceptionHandler, placed it in the HLRC configurations, and threw an exception in the callback to simulate the problem. However, the exception in the callback was not captured by the I/O Reactor ExceptionHandler, and no exception was thrown during script execution. It was difficult to verify the function of the I/O Reactor ExceptionHandler. According to the verification results from other developers in the Elasticsearch community, no problems have occurred since they added the I/O Reactor ExceptionHandler a long time ago. You are advised to configure the I/O Reactor ExceptionHandler, but do not ignore all exceptions.

   The Elasticsearch REST client should provide an exception handler instead of asking users to configure the I/O Reactor ExceptionHandler, which cannot solve all exceptions.

Solution

1. Adjust the size of the client connection pool based on the site requirements.
2. You are advised to adjust the number of concurrent clients based on the site requirements or configure multiple nodes to share the pressure.
3. You are advised to configure the I/O Reactor ExceptionHandler to handle some exceptions.
4. After the HLRC is called, catch exceptions and check whether they occurred because the I/O Reactor status had changed to STOPPED. Restart the client to restore the connection.