https://issues.apache.org/bugzilla/show_bug.cgi?id=57520
Yann Ylavic <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |NEEDINFO --- Comment #1 from Yann Ylavic <[email protected]> --- (In reply to dk from comment #0) > I have been stress-testing fault tolerance of an Apache load balancer with > Jetty backend being restarted under heavy load. Is Jetty gracefully restarted here? If not, you probably can't expect zero error here, say a request (including body) has been forwarded by mod_proxy while Jetty issues an abortive restart, there is nothing that can be recovered, an error will occur on the proxy side while "reading status line from remote server". What is the exact error line printed? > > Our test requests involve downloading of large XML documents (in HTTP > request bodies) with heavy custom processing before response - which means > the full requests take between 100-1000ms depending of the system load. You mean *uploading* a large XML document to Jetty right? And then Jetty takes up to 1s to generate a response or is the request taking that time to be forwarded to Jetty (not including response)? > > Initially, I have been getting errors similar to the ones described in Bug > 37770, so I applied all the proposed fixes in all possible combinations > (HTTP 1.0, no keepalive, initial not pooled, etc) - however the same errors > as in Bug 37770 kept re-appearing from time to time. > > Then I noticed that our Jetty servlet occasionally fails to read HTTP input > stream - encountering and logging an early EOF. Seems to me the ONLY > possible cause of this condition would be if httpd forcefully closed the > connection for currently executing requests. This could also happen if the read failed on the client side while mod_proxy forwards the (large) request. > This could occur once Jetty has > stopped accepting new requests, but have not yet finished processing > existing ones - it would return an error to httpd, which would mark the > worker as failed and kill existing connections. This condition would be > noticeable with large requests under heavy load. If that happens, you should see "disabling worker" messages in the error log, is it the case? > > I wonder if this theory makes sense and if a fix could be developed. I think we need at least the error log and configuration file on the httpd side, as well as the KeepAlive timeout value (and connection related ones) on the Jetty side. -- You are receiving this mail because: You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
