Oleg, is there anything else we should know about the details of this problem on the 4.x line? It seems like there's more going on here than just a missing `catch` block.
On Thu, Jun 18, 2020 at 11:48 AM Oleg Kalnichevski <[email protected]> wrote: > 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] > >
