From b6029cbafca71163ba007ddd0723bbadf58b4e3e Mon Sep 17 00:00:00 2001
From: Graham Leggett <minfrin@apache.org>
Date: Mon, 29 Apr 2013 14:19:19 +0000
Subject: [PATCH] Update the docs to note that SSL now works with the event MPM
 as per r1470679.

git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1477094 13f79535-47bb-0310-9956-ffa450edef68
---
 docs/manual/mod/event.xml | 17 +++++++++--------
 1 file changed, 9 insertions(+), 8 deletions(-)

diff --git a/docs/manual/mod/event.xml b/docs/manual/mod/event.xml
index c27136058d..7031cfb37a 100644
--- a/docs/manual/mod/event.xml
+++ b/docs/manual/mod/event.xml
@@ -60,10 +60,11 @@ of consuming threads only for connections with active processing</description>
     status page of <module>mod_status</module> shows how many connections are
     in the mentioned states.</p>
 
-    <p>The improved connection handling does not yet work for certain
-    connection filters, in particular SSL. For SSL connections, this MPM will
-    fall back to the behaviour of the <module>worker</module> MPM and
-    reserve one worker thread per connection.</p>
+    <p>The improved connection handling may not work for certain connection
+    filters that have declared themselves as incompatible with event. In these
+    cases, this MPM will fall back to the behaviour of the
+    <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>The MPM assumes that the underlying <code>apr_pollset</code>
     implementation is reasonably threadsafe. This enables the MPM to
@@ -152,10 +153,10 @@ of consuming threads only for connections with active processing</description>
 <usage>
     <p>The event MPM handles some connections in an asynchronous way, where
     request worker threads are only allocated for short periods of time as
-    needed, and other (mostly SSL) connections with one request worker thread
-    reserved per connection. This can lead to situations where all workers are
-    tied up and no worker thread is available to handle new work on established
-    async connections.</p>
+    needed, and other connections with one request worker thread reserved per
+    connection. This can lead to situations where all workers are tied up and
+    no worker thread is available to handle new work on established async
+    connections.</p>
 
     <p>To mitigate this problem, the event MPM does two things: Firstly, it
     limits the number of connections accepted per process, depending on the
-- 
2.40.0