On Thu, 2020-06-18 at 10:18 -0700, Ryan Schmitt wrote: > 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. >
Hi Rui I _think_ most of the technical issues have already been addressed in HC 5.0. I am not sure HC 4.x is worth any major refactoring efforts at this point but you are certainly welcome to propose a PR for the 4.x release branch. The only potentially contentious issue might be handing of Errors but I am sure we can work something out. Please do however consider upgrading to HC 5.0 Cheers Oleg --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
