Return-Path: Delivered-To: apmail-apache-bugdb-archive@apache.org Received: (qmail 50584 invoked by uid 500); 15 Mar 2001 18:49:03 -0000 Mailing-List: contact apache-bugdb-help@apache.org; run by ezmlm Precedence: bulk Reply-To: apache-bugdb@apache.org list-help: list-unsubscribe: list-post: Delivered-To: mailing list apache-bugdb@apache.org Received: (qmail 50212 invoked by uid 501); 15 Mar 2001 18:48:56 -0000 Date: 15 Mar 2001 18:48:56 -0000 Message-ID: <20010315184856.50203.qmail@apache.org> To: apache-bugdb@apache.org, rgriswol@us.ibm.com, trawick@apache.org From: trawick@apache.org Subject: Re: os-aix/7418: Incorrect reporting of bytes sent by send_file() [In order for any reply to be added to the PR database, you need] [to include in the Cc line and make sure the] [subject line starts with the report component and number, with ] [or without any 'Re:' prefixes (such as "general/1098:" or ] ["Re: general/1098:"). If the subject doesn't match this ] [pattern, your message will be misfiled and ignored. The ] ["apbugs" address is not added to the Cc line of messages from ] [the database automatically because of the potential for mail ] [loops. If you do not include this Cc, your reply may be ig- ] [nored unless you are responding to an explicit request from a ] [developer. Reply only with text; DO NOT SEND ATTACHMENTS! ] Synopsis: Incorrect reporting of bytes sent by send_file() Comment-Added-By: trawick Comment-Added-When: Thu Mar 15 10:48:54 PST 2001 Comment-Added: >From your patch, I suspect that you misundersood the intended semantics of apr_sendfile(). Hopefully my follow-up questions and/or comments below will help sort out where the misunderstanding may lie. >The apr_sendfile() function in the srclib/apr/network_io/unix/sendrecv.c >only reports the number of bytes sent by the last call to send_file. What do you think it should report? >The code also only checks for a return code of -1, and not a return >code of 1 which indicates that send_file() was able to send part of >the data, but not all of it. Why does apr_sendfile() care? It merely needs to tell the caller how much data was sent, and it knows by looking at the updated parms.bytes_sent field. >On AIX this results in a minor performance degradation since >Apache has to make multiple calls to the apr_sendfile() >function to send large files. The same is true of other routines which write on a socket. We do not hang around inside APR write-to-the-network routines until all data has been written. Note that the socket used by Apache has been marked non-blocking. We expect that multiple syscalls will be used to send large files. In return, we are able to control when we give up on send_file() and decide to drop the connection because of a timeout. We *could* do the multiple-syscall repeat inside APR but have not chosen to do so. >However, on a version of one of our operating systems currently under >developement (I could tell you which one, but then I'd have to kill >you :)) it causes Apache to fail to send files larger than twice >the send buffer size. Maybe if you can answer my questions above I'll understand. Is there a bug in the code which calls apr_sendfile() which prevents it from being able to call apr_sendfile() enough times? About the future AIX change: Does this mean that OS/390 and AIX can no longer use the same apr_sendfile() implementation at that point? That would suck. I look forward to your update.