Return-Path: Delivered-To: apmail-httpd-bugs-archive@www.apache.org Received: (qmail 43197 invoked from network); 14 Sep 2005 19:32:47 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 14 Sep 2005 19:32:47 -0000 Received: (qmail 43191 invoked by uid 500); 14 Sep 2005 19:32:46 -0000 Delivered-To: apmail-httpd-bugs-archive@httpd.apache.org Received: (qmail 43159 invoked by uid 500); 14 Sep 2005 19:32:45 -0000 Mailing-List: contact bugs-help@httpd.apache.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: Reply-To: "Apache HTTPD Bugs Notification List" List-Id: Delivered-To: mailing list bugs@httpd.apache.org Received: (qmail 43144 invoked by uid 99); 14 Sep 2005 19:32:45 -0000 X-ASF-Spam-Status: No, hits=0.2 required=10.0 tests=NO_REAL_NAME X-Spam-Check-By: apache.org Received: from [192.87.106.226] (HELO ajax.apache.org) (192.87.106.226) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 14 Sep 2005 12:32:45 -0700 Received: by ajax.apache.org (Postfix, from userid 99) id 4293B136; Wed, 14 Sep 2005 21:32:44 +0200 (CEST) From: bugzilla@apache.org To: bugs@httpd.apache.org Subject: DO NOT REPLY [Bug 36636] - blocking writev()/poll()-call causes mod_dav to stop responding X-Bugzilla-Reason: AssignedTo Message-Id: <20050914193244.4293B136@ajax.apache.org> Date: Wed, 14 Sep 2005 21:32:44 +0200 (CEST) X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG� RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND� INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=36636 ------- Additional Comments From arne@arne.net 2005-09-14 21:32 ------- Thank you so much for your help! I put a check for f->c->aborted in core.c:core_output_filter and thereby reduced the number of timed out writes to one. But the core issue still remains. I am sending this prepared PROPFIND which causes a large answer, and each request will just stop sending ACKs in the middle of the transaction. In about 1 in 10 cases (or so), the behaviour changes and the poll() locks, it is always with the same data to write, with the exact same packets being sent by the client. A "normal" situation looks like this: 20:52:09.407647 [ffffe410] writev(8, [...], 3) = 3686 <0.000013> 20:52:09.409004 [ffffe410] writev(8, [{"1f5e\r\n", 6}, ...], 4) = 5074 <0.000014> 20:52:09.409095 [ffffe410] poll([{fd=8, events=POLLOUT, revents=POLLERR|POLLHUP}], 1, 300000) = 1 <0.246947> 20:52:09.656085 [ffffe410] writev(8, [...], 3) = -1 EPIPE (Broken pipe) <0.000013> 20:52:09.656163 [ffffe410] --- SIGPIPE (Broken pipe) @ 0 (0) --- This I can strace all the time, but occasionally, it is this: 20:57:26.463493 [ffffe410] writev(8, [...], 4) = 1800 <0.000014> 20:57:26.463608 [ffffe410] poll([{fd=8, events=POLLOUT, revents=POLLOUT}], 1, 300000) = 1 <0.011306> 20:57:26.474956 [ffffe410] writev(8, [...], 3) = 6250 <0.000022> 20:57:26.476328 [ffffe410] writev(8, [{"1f5e\r\n", 6},...], 4) = 2510 <0.000012> 20:57:26.476424 [ffffe410] poll([{fd=8, events=POLLOUT}], 1, 300000) = 0 <299.851111> In the latter case, poll does not return the POLLERR. The connection is then in CLOSED_WAIT, after a while, it goes to LAST_ACK (while the send-Q is 20k). I read something about the behaviour on http://www.ussg.iu.edu/hypermail/linux/kernel/0407.3/0495.html but I'm not sure if this is intended in this case. Is it the kernel or apache that is loosing track of the FD? Why is the kernel not signalling the SIGPIPE / POLLERR? -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. --------------------------------------------------------------------- To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org For additional commands, e-mail: bugs-help@httpd.apache.org