Here is what I am testing: I am using (currently one) mod_proxy_fcgi member in 
a balancer to php-fpm. I have already run into some issues with fcgi:// as a 
balancer member as described in 
<http://mail-archives.apache.org/mod_mbox/httpd-dev/201109.mbox/%3CB0DADBC2-5154-4C37-93B5-D38B834BE571%40riggs.me%3E>.
 So, I have applied a small patch to httpd and php to get around these issues.

Everything has been working perfectly, but we noticed that some uploads fail 
with a 503. (We could upload a 181KB file but not 182KB.) I spent considerable 
time debugging and tracing the issue. I finally tracked this down to 
send_data() in mod_proxy_fcgi. While looping over the calls to 
apr_socket_sendv(), it would make 23 successful calls of 8200 bytes followed by 
a partial send and then receive EAGAIN. Because this is not APR_SUCCESS, it 
breaks the loop in the next line and returns a 503.

Since it received EAGAIN, I just brute-forced it to not break the loop on 
EAGAIN, but what is the correct fix? Is there something wrong in my setup? Is 
it a bug? Should send_data() be handling EAGAIN and continue the loop up to a 
timeout?

Your thoughts are appreciated.

- Jim


My brute-force hack:

--- mod_proxy_fcgi.c.orig       2012-02-03 13:23:09.132232659 -0600
+++ mod_proxy_fcgi.c    2012-02-03 13:25:19.794906516 -0600
@@ -188,7 +188,7 @@
     while (to_write) {
         apr_size_t n = 0;
         rv = apr_socket_sendv(s, vec + offset, nvec - offset, &n);
-        if (rv != APR_SUCCESS) {
+        if ((rv != APR_SUCCESS) && !APR_STATUS_IS_EAGAIN(rv)) {
             break;
         }
         if (n > 0) {

Reply via email to