> -----Original Message----- > From: Oleg Kalnichevski [mailto:[email protected]] > Sent: Tuesday, May 31, 2016 3:04 PM > To: HttpComponents Project <[email protected]> > Subject: Re: BasicAsyncResponseConsumer needs OOM protection? > > On Tue, 2016-05-31 at 16:03 +0000, Idzerda, Edan wrote: > > Using this patch, I can request HTTP responses that exceed available > memory without resulting in a hang. Does this seem like the appropriate > place to patch this error? Or should I create a JIRA against this issue and > suggest this patch as a solution? I've attached a diff to this email > > > > Thanks for your assistance and for working on such a great set of Java > libraries. > > Edan > > Basic request / response consumers are not supposed to be used for > anything other than the most basic use cases. One is generally advised > to build custom response consumers specifically tailed to their > particular application.
I understand that, and thanks for the other examples. For what it's worth, I have load tested the reverse proxy using the BasicAsyncResponseConsumer and it performs extremely well with small messages. However, if a developer uses the HttpAsyncClient without specifying a specific response consumer, they are using this Basic one by default. If they happen to experience an OOM condition because their heap cannot handle a response size, the NIO Connection Pool cannot make any new requests. I found this difficult to debug because I assumed the connection pool would recover from this unexpected condition. Isn't the AbstractMultiworkerIOReactor expecting that any error like this would be captured by the response consumer? If that's true, shouldn't the BasicAsyncResponseConsumer suppress a hard error like OOM to prevent this problem? Or should the IOReactor layer recover better? Thanks again for your efforts on this project. - edan
