https://bz.apache.org/bugzilla/show_bug.cgi?id=57921
--- Comment #8 from Philippe Mouawad <[email protected]> --- (In reply to Rainer Jung from comment #7) > (In reply to Philippe Mouawad from comment #4) > > Maybe we should change retry defaults: > > - https://bugzilla.mozilla.org/show_bug.cgi?id=92224 > > That is about a special situation for requests including a request body. > > The problem here is about a request (with or without body) that tried to use > a stale connection. Stale in the sense that the HTTP keepa-live timeout was > reached or almost reached. > > It is also not about general retries. It would be good, if we could fix the > keep-alive timeout issue. To me it seems that HTTPClient should handle keep > alives itself well. After the keep alive timeout happened, it should not > resuse a connection. There's a DefaultConnectionKeepAliveStrategy that > supports that. Maybe we have to activate it or so. > > But there's always a small chance for a race condition (timeout not yet over > when sending data but timeout reached before data arrives at server), it > might be best to not reuse a keep alive connection if at the moment we want > to use it the keep alive timeout is nearly over. > > It seems that HTTPClient allows to define a ConnectionKeepAliveStrategy > which can be derived from DefaultConnectionKeepAliveStrategy and would set > the keep alive timeout e.g. to the one determined by > DefaultConnectionKeepAliveStrategy from the server header minus e.g. 200 ms > (configurable). Not perfect but should reduce those race conditions a lot. > sebb implemented in 2.11 I think a httpclient4.idletimeout property that if > 0, would setup custom DefaultConnectionKeepAliveStrategy that would artificially set a default keep alive if server didn't set it correctly. Maybe we could enhance it > I think we first have to find out whether and why the general keep alive > case is broken and then can tackle the rare race condition. -- You are receiving this mail because: You are the assignee for the bug.
