DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20295>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20295 Uploading large multipart/form-data sometimes fails ------- Additional Comments From [EMAIL PROTECTED] 2003-06-03 13:22 ------- Using a binary upload file of approx 17K, the following behaviour seems fairly consistent in this test: 1. apr_file_write() called and writes 8000 bytes to FD ok and returns. 2. apr_file_write() called and writes 192 bytes to FD ok and returns. 3. apr_file_write() called, but blocks (11:EAGAIN) on first write() attempt. apr_wait_for_io_or_timeout() returns APR_SUCCESS. Second attempt at write is successful (8000 bytes on FD). 4. apr_file_write() called, but blocks (11:EAGAIN) on first write() attempt. apr_wait_for_io_or_timeout()returns APR_SUCCESS. Second attempt also blocks (11:EAGAIN), which returns a non-successful return code to calling function - thus killing upload. >From my tests I'm fairly sure that the poll code is correct. It seems to be calling poll() on the correct FD and revents is being set to POLLOUT (0x0100) as expected. However, this sill results in the following call to write() on the same FD blocking. My only thought on this is the following from poll(2) on HP-UX: << The conditions indicated by POLLNORM and POLLOUT are true if and only if at least one byte of data can be read or written without blocking. The exception is regular files, which always poll true for POLLNORM and POLLOUT. Also, streams return POLLNORM in revents even if the available message is of zero length. >> I'm guessing that poll() is setting POLLOUT to always be true, hence the following call to write() may still block. For the CGI client FD, pollset.desc_type = APR_POLL_FILE. My fix was to return a compliance of success after the initial write() blocks (with zero bytes written). I'm guess that the FD will no longer block when apr_file_write() is next called (because of slightly longer delay), else it blocks and we go around again. If the above poll behaviour isn't the answer then I'm stuck at this point. Another question is whether there are any HP-UX 11 patches available that affect poll/write, etc. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
