Re: mod_proxy buffering small chunks
-Ursprüngliche Nachricht- Von: Mladen Turk Gesendet: Freitag, 13. April 2007 07:07 An: [EMAIL PROTECTED] Betreff: Re: mod_proxy buffering small chunks Jim Jagielski wrote: This is only fixed in trunk so far. See http://issues.apache.org/bugzilla/show_bug.cgi?id=41056 and http://svn.apache.org/viewvc?view=revrevision=480135 Hmmm. Looks like a backport candidate... I'll likely do some testing and propose if it works :) +1 I will try to check it once you have proposed it and give it a quick vote. I have another one that fixes this issues for non-chunked content. I haven't tried yet, but IMHO it should already work for non-chunked content. Is this not the case? I've tested this and a flushwait=timeout can work very well with mod_proxy_http. The principle is the same as Rudiger did for ajp. Although I introduced the flushwait solution for ajp (which is partly obsolete with later Tomcats thanks to your patch which takes empty ajp chunk messages as a flushing request) and still think it is a good idea I like the approach of mod_proxy_http even more as it works without further configuration and is even smarter. Regards Rüdiger
Re: mod_proxy buffering small chunks
Plüm wrote: +1 I will try to check it once you have proposed it and give it a quick vote. I have another one that fixes this issues for non-chunked content. I haven't tried yet, but IMHO it should already work for non-chunked content. Is this not the case? Not according to my tests. The simple server push still buffers the data. I've tested this and a flushwait=timeout can work very well with mod_proxy_http. The principle is the same as Rudiger did for ajp. Although I introduced the flushwait solution for ajp (which is partly obsolete with later Tomcats thanks to your patch which takes empty ajp chunk messages as a flushing request) and still think it is a good idea I like the approach of mod_proxy_http even more as it works without further configuration and is even smarter. flushwait still works with older Tomcat versions that do not send a separate 'explicit flush' packet, and IMHO that is the only solution for http. I'm not speaking here about Tomcat, but a generic standalone backends and http/1.0 clients that have problems with chunked encodings. Anyhow, I'll commit a patch to the trunk for http, cause its configurable by flushwait and skipped otherwise. Regards, Mladen.
Re: mod_proxy buffering small chunks
On Apr 13, 2007, at 5:20 AM, Mladen Turk wrote: Anyhow, I'll commit a patch to the trunk for http, cause its configurable by flushwait and skipped otherwise. Looking forward to seeing it... recall that if we flush at every chunk with HTTP, we will be dead slow and filters will not be happy :)
Re: mod_proxy buffering small chunks
On Apr 13, 2007, at 5:20 AM, Mladen Turk wrote: Plüm wrote: +1 I will try to check it once you have proposed it and give it a quick vote. I have another one that fixes this issues for non-chunked content. I haven't tried yet, but IMHO it should already work for non-chunked content. Is this not the case? Not according to my tests. The simple server push still buffers the data. Hmmm a followup commit has: URL: http://svn.apache.org/viewvc?view=revrev=504559 Log: Further refinement for PR41056 / PR 19954 (mostly-fixed in r480135.) We assume that a successful read but an empty brigade is NOT cause for EAGAIN. Testing may or may not confirm this assumption, in which case that test may be required as well. so that may be exactly the case...
Re: mod_proxy buffering small chunks
On Apr 13, 2007, at 11:34 AM, Jim Jagielski wrote: On Apr 13, 2007, at 5:20 AM, Mladen Turk wrote: Plüm wrote: +1 I will try to check it once you have proposed it and give it a quick vote. I have another one that fixes this issues for non-chunked content. I haven't tried yet, but IMHO it should already work for non-chunked content. Is this not the case? Not according to my tests. The simple server push still buffers the data. Hmmm a followup commit has: URL: http://svn.apache.org/viewvc?view=revrev=504559 Log: Further refinement for PR41056 / PR 19954 (mostly-fixed in r480135.) We assume that a successful read but an empty brigade is NOT cause for EAGAIN. Testing may or may not confirm this assumption, in which case that test may be required as well. so that may be exactly the case... I refer people to http://mail-archives.apache.org/mod_mbox/httpd-dev/200702.mbox/% [EMAIL PROTECTED] ... so maybe a successful read of an empty line in AP_MODE_GET_LINE does *not* return an empty brigade... We currently assuming it does. Anyone able to test if Rüdiger's version addresses this?
Re: mod_proxy buffering small chunks
Jim Jagielski wrote: Not according to my tests. The simple server push still buffers the data. Hmmm a followup commit has: URL: http://svn.apache.org/viewvc?view=revrev=504559 so that may be exactly the case... Huh, looks like it works now. Although I didn't test is with mod_deflate, but I suppose it should work as well. Can we get those back trough 2.0? Regards, Mladen.
Re: mod_proxy buffering small chunks
On Apr 13, 2007, at 12:03 PM, Mladen Turk wrote: Jim Jagielski wrote: Not according to my tests. The simple server push still buffers the data. Hmmm a followup commit has: URL: http://svn.apache.org/viewvc?view=revrev=504559 so that may be exactly the case... Huh, looks like it works now. Although I didn't test is with mod_deflate, but I suppose it should work as well. Can we get those back trough 2.0? Def for 2.2 (maybe you were testing 2.2 and not trunk??)... I'll see how much can actually go to 2.0 :)
Re: mod_proxy buffering small chunks
On Apr 11, 2007, at 3:34 PM, Ruediger Pluem wrote: On 04/11/2007 06:42 PM, Filipe wrote: I'm trying to use apache to proxy a push application, using chunked transfer encoding. The problem is that the mod_proxy buffers the server response internally and only sends the data to the client when the buffer is filled or the connection with the server is terminated. This behavior is not adequate for push applications, where the response must be redirected instantly to the http client. This problem was discussed a year ago: http://mail-archives.apache.org/mod_mbox/httpd-dev/200602.mbox/raw/ [EMAIL PROTECTED]/ This is only fixed in trunk so far. See http://issues.apache.org/bugzilla/show_bug.cgi?id=41056 and http://svn.apache.org/viewvc?view=revrevision=480135 Hmmm. Looks like a backport candidate... I'll likely do some testing and propose if it works :)
Re: mod_proxy buffering small chunks
Jim Jagielski wrote: This is only fixed in trunk so far. See http://issues.apache.org/bugzilla/show_bug.cgi?id=41056 and http://svn.apache.org/viewvc?view=revrevision=480135 Hmmm. Looks like a backport candidate... I'll likely do some testing and propose if it works :) I have another one that fixes this issues for non-chunked content. I've tested this and a flushwait=timeout can work very well with mod_proxy_http. The principle is the same as Rudiger did for ajp. Regards, Mladen.
Re: mod_proxy buffering small chunks
On 04/11/2007 06:42 PM, Filipe wrote: I'm trying to use apache to proxy a push application, using chunked transfer encoding. The problem is that the mod_proxy buffers the server response internally and only sends the data to the client when the buffer is filled or the connection with the server is terminated. This behavior is not adequate for push applications, where the response must be redirected instantly to the http client. This problem was discussed a year ago: http://mail-archives.apache.org/mod_mbox/httpd-dev/200602.mbox/raw/[EMAIL PROTECTED]/ This is only fixed in trunk so far. See http://issues.apache.org/bugzilla/show_bug.cgi?id=41056 and http://svn.apache.org/viewvc?view=revrevision=480135 Regards Rüdiger
Re: mod_proxy buffering small chunks
* Alan Gutierrez [EMAIL PROTECTED] [2006-02-13 15:48]: * Plüm, Rüdiger, VIS [EMAIL PROTECTED] [2006-02-06 09:29]: -Ursprüngliche Nachricht- Von: Alan Gutierrez The proposed solution is to poll for chunks using non-blocking I/O. When the socket returns EAGAIN, the 8K buffer is flushed, and the socket is read with blocking I/O. Thats the way the code is already designed in 2.2.x. I am aware of this, acutally. I should have noted this myself. I've traced through the code to see where the EAGAIN return value is lost, and to note that the non-blocking mode is not applied to the header. I've not tested, but I suspect that the logic is correctly implemented should the socket block during the transfer of the body of a chunk. It fails when the next chunk has not been sent. However, in the http code, regardless of the block mode flag, the headers are read using blocking I/O. Furthermore, somewhere deeper in the chain, when EAGAIN is detected the success flag is returned instead. I'll provide more detail, if this is not already well known. This is the problem. The EAGAIN or better the mode handling in this code path is somewhat broken. Looks that way. The EAGAIN is never sent back out, and in addition the headers are read with a blocking read. It would require changing the return values of code path, which may way cause some breakage. Maybe not, if EAGAIN is handled correctly in all places, but it's never been tested, since it's never returned, right? Looks like this is going to be messy to fix. Any patches? Not so far. I guess it requires some general changes that must be carefully designed. But anyway, patch proposals are welcome :-). Can I suggest a flag? Something like ProxyChunkedAsIs On What does anyone think? -- Alan Gutierrez - 504 717 1428 - [EMAIL PROTECTED] - http://blogometer.com/
Re: mod_proxy buffering small chunks
* Plüm, Rüdiger, VIS [EMAIL PROTECTED] [2006-02-06 09:29]: -Ursprüngliche Nachricht- Von: Alan Gutierrez The proposed solution is to poll for chunks using non-blocking I/O. When the socket returns EAGAIN, the 8K buffer is flushed, and the socket is read with blocking I/O. Thats the way the code is already designed in 2.2.x. I am aware of this, acutally. I should have noted this myself. I've traced through the code to see where the EAGAIN return value is lost, and to note that the non-blocking mode is not applied to the header. I've not tested, but I suspect that the logic is correctly implemented should the socket block during the transfer of the body of a chunk. It fails when the next chunk has not been sent. However, in the http code, regardless of the block mode flag, the headers are read using blocking I/O. Furthermore, somewhere deeper in the chain, when EAGAIN is detected the success flag is returned instead. I'll provide more detail, if this is not already well known. This is the problem. The EAGAIN or better the mode handling in this code path is somewhat broken. Looks that way. The EAGAIN is never sent back out, and in addition the headers are read with a blocking read. It would require changing the return values of code path, which may way cause some breakage. Maybe not, if EAGAIN is handled correctly in all places, but it's never been tested, since it's never returned, right? Looks like this is going to be messy to fix. Any patches? Not so far. I guess it requires some general changes that must be carefully designed. But anyway, patch proposals are welcome :-). Can I suggest a flag? Something like ProxyChunkedAsIs On If this could be specified for a path or directory, then the upstream chunks are sent immediately, no buffering what so ever. This is a patch I've applied partially, need to add the flag. Adding the behavior fixes my problem. I'm proxying a stock ticker. The chunk size is always going to be smaller than 8k. Even when the EAGAIN logic is implemented correctly, buffering is liable to delay the receipt of the chunk. Actually, the thing you want works with mod_proxy_ajp in 2.2.x. AJP? Confusing. Wish I could keep it HTTP. -- Alan Gutierrez - 504 717 1428 - [EMAIL PROTECTED] - http://blogometer.com/
