From: Stefan Fritsch <sf@apache.org>
Date: Thu, 15 Aug 2013 09:17:10 +0000 (+0000)
Subject: Try to document the current behavior of MPM event with filters like mod_ssl,
X-Git-Tag: 2.5.0-alpha~5189
X-Git-Url: https://granicus.if.org/sourcecode?a=commitdiff_plain;h=89801f1e0501b95a9505918bc8dce0d04117d4c0;p=apache

Try to document the current behavior of MPM event with filters like mod_ssl,
mod_deflate, or mod_include


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1514214 13f79535-47bb-0310-9956-ffa450edef68
---

diff --git a/docs/manual/mod/event.xml b/docs/manual/mod/event.xml
index 7031cfb37a..764608c164 100644
--- a/docs/manual/mod/event.xml
+++ b/docs/manual/mod/event.xml
@@ -66,6 +66,14 @@ of consuming threads only for connections with active processing</description>
     <module>worker</module> MPM and reserve one worker thread per connection.
     All modules shipped with the server are compatible with the event MPM.</p>
 
+    <p>A similar restriction is currently present for requests involving an
+    output filter that needs to read and/or modify the whole response body,
+    like for example mod_ssl, mod_deflate, or mod_include. If the
+    connection to the client blocks while the filter is processing the
+    data, and the amount of data produced by the filter is too big to be
+    buffered in memory, the thread used for the request is not freed while
+    httpd waits until the pending data is sent to the client.</p>
+
     <p>The MPM assumes that the underlying <code>apr_pollset</code>
     implementation is reasonably threadsafe. This enables the MPM to
     avoid excessive high level locking, or having to wake up the listener