You are viewing a plain text version of this content. The canonical link for it is here.
Posted to cvs@httpd.apache.org by sf...@apache.org on 2013/08/15 11:17:10 UTC
svn commit: r1514214 - /httpd/httpd/trunk/docs/manual/mod/event.xml
Author: sf
Date: Thu Aug 15 09:17:10 2013
New Revision: 1514214
URL: http://svn.apache.org/r1514214
Log:
Try to document the current behavior of MPM event with filters like mod_ssl,
mod_deflate, or mod_include
Modified:
httpd/httpd/trunk/docs/manual/mod/event.xml
Modified: httpd/httpd/trunk/docs/manual/mod/event.xml
URL: http://svn.apache.org/viewvc/httpd/httpd/trunk/docs/manual/mod/event.xml?rev=1514214&r1=1514213&r2=1514214&view=diff
==============================================================================
--- httpd/httpd/trunk/docs/manual/mod/event.xml (original)
+++ httpd/httpd/trunk/docs/manual/mod/event.xml Thu Aug 15 09:17:10 2013
@@ -66,6 +66,14 @@ of consuming threads only for connection
<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