On Thu, 2020-06-18 at 12:55 -0700, Ryan Schmitt wrote: > 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. >
I would not really define it as a problem. It is just a fundamental principle that is is generally better to terminate i/o endpoints in case of an unexpected condition the framework does not know how to gracefully recover from than leaving them running in a half-broken or inconsistent state. If you want to keep endpoints running in case of a unexpected runtime exception in the application layer, so be it, but just apply that it consistently across the entire i/o and protocol layers. Oleg > 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] > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
