From 89801f1e0501b95a9505918bc8dce0d04117d4c0 Mon Sep 17 00:00:00 2001 From: Stefan Fritsch Date: Thu, 15 Aug 2013 09:17:10 +0000 Subject: [PATCH] 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 --- docs/manual/mod/event.xml | 8 ++++++++ 1 file changed, 8 insertions(+) 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 worker MPM and reserve one worker thread per connection. All modules shipped with the server are compatible with the event MPM.

+

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.

+

The MPM assumes that the underlying apr_pollset implementation is reasonably threadsafe. This enables the MPM to avoid excessive high level locking, or having to wake up the listener -- 2.40.0