Forwarding this along, since it's not making it to the list for some reason.
---------- Forwarded message --------- From： xzer <[email protected]> Date: 2020/6/17/ 10:59PM Subject: About HttpAsyncClient exception handling mechanism To: <[email protected]> Hello, I am writing this mail to pursue the possible improvement on the current HttpAsyncClient exception handling mechanism. We observed many service failures inside our company with the error of “I/O reactor status: STOPPED” when using Apache HttpAsyncClient, we also know the reason is because the IOReactorExceptionHandler is not set correctly. For reference: https://hc.apache.org/httpcomponents-core-ga/httpcore-nio/apidocs/org/apache/http/impl/nio/reactor/AbstractMultiworkerIOReactor.html We noticed that there are several things should be taken into consideration as this kind of "mistake" keeps happening: - There is almost no guidance information about IOReactorExceptionHandler at the official site except a small paragraph in tutorial. The official example of how to customize and configure the client building does not have IOReactorExceptionHandler configured too. - The example of quick start is using "HttpAsyncClients.createDefault()" to illustrate the out-of-box usage, but the client instance created by which "quick way" does not have IOReactorExceptionHandler configured too. - Even we configure the IOReactorExceptionHandler to handle the Exceptions, we still have several concerns: - Is that safe to resume the IO Reactor unconditionally on any Exception? - It is still impossible to recover the IO Reactor if there is an Error rather than Exception, which is typically happening when the service is under traffic pressure. For the final point of Exception/Error recovery, we understand that it is difficult to decide how to handle the Exception/Error at library level as we have less knowledge about the runtime context. However, it is a painful task to developers who have to take the robustness into account. We believe that HttpAsyncClient should provide extra robustness mechanism to simplify the usage. We have a proposal like following: - The client instance created by "HttpAsyncClients.createDefault()" should have a default IOReactorExceptionHandler configured. - The guidance information of setting IOReactorExceptionHandler should be added into the example of customizing. - We also propose a default strategy of Exception handling as: resume on RuntimeException and crash on IOException, which is based on a hypothesis that RuntimeException is usually caused by user code and IOException is more likely suggesting a underlying network communication failure. - We also propose a mechanism which will check the IOReactor status and then reinitialize the client instance entirely when uncaught Exception/Error happens. As the proposal still requires polish and discussion, thus we are sending this mail to ask the opinion from you about it. Best Regards Rui Liu Sr SDE | Amazon IN Core CX Tech
