>Number: 2073 >Category: mod_log-any >Synopsis: pipelined connections are not logged correctly >Confidential: no >Severity: non-critical >Priority: medium >Responsible: apache >State: open >Class: sw-bug >Submitter-Id: apache >Arrival-Date: Fri Apr 17 15:30:00 PDT 1998 >Last-Modified: >Originator: [EMAIL PROTECTED] >Organization: apache >Release: 1.2, 1.3 >Environment: all >Description: When a connection is pipelined, Apache may log that a response was sent even before it has flushed the response to the kernel. So the response may never be sent, but will show in the log as having been sent. A less serious problem is that the "duration" of the request is wrong... but given that number is always wrong it's less of a concern (apache never knows when the kernel has actually sent the response). >How-To-Repeat:
>Fix: One possible solution was implemented and posted to new-httpd, see Message-ID <[EMAIL PROTECTED]> in the february 1998 archives. However this solution has a rather large drawback in that it chews a bunch of memory because it needs to keep each request pool around as long as the request still has data in Apache's buffer. For future reference in API design, a less expensive solution is to do logging in two steps. One step happens at the end of the request, when the full request_rec is available. At this point the logger should not log -- it should be given another pool to allocate whatever it wants in. Then later when the response is actually flushed from Apache's buffers the logger should be called again and given the opportunity to log. That is to say, logging should become two phase. The first phase copies the relevant log data from the request_rec into another pool. That way the main request pool can be cleared to free up memory. Then the second phase actually performs the logging using the copied data >Audit-Trail: >Unformatted: [In order for any reply to be added to the PR database, ] [you need to include <[EMAIL PROTECTED]> in the Cc line ] [and leave the subject line UNCHANGED. This is not done] [automatically because of the potential for mail loops. ]
