From 0d90338a46a0ede7095c885188acccac89e30203 Mon Sep 17 00:00:00 2001
From: Kyle Banker <kylebanker@gmail.com>
Date: Thu, 10 Feb 2011 15:13:28 -0500
Subject: [PATCH] minor: docs

---
 README.md   | 18 +++++++++++++++---
 docs/FAQ.md |  4 ++++
 2 files changed, 19 insertions(+), 3 deletions(-)

diff --git a/README.md b/README.md
index 10611ad..02710cb 100644
--- a/README.md
+++ b/README.md
@@ -129,7 +129,7 @@ The driver is thread-safe.
 
 ## Connection Pooling
 
-As of v0.18, the driver implements connection pooling. By default, only one
+The driver implements connection pooling. By default, only one
 socket connection will be opened to MongoDB. However, if you're running a
 multi-threaded application, you can specify a maximum pool size and a maximum
 timeout for waiting for old connections to be released to the pool.
@@ -149,12 +149,24 @@ processes will create a new connection to the database. In Passenger, this can b
     if defined?(PhusionPassenger)
       PhusionPassenger.on_event(:starting_worker_process) do |forked|
         if forked
-          # Create new connection here
+          # Reset all connection objects. How you do this depends on where
+          # you keep your connection object. In any case, call the #connect
+          # method on the connection object. For example:
+          # CONN.connect
+          #
+          # If you're using MongoMapper:
+          # MongoMapper.connection.connect
         end
       end
     end
 
-The above code should be put into a Rails initializer or other initialization script.
+In Unicorn, add this to your unicorn.rb file:
+
+    after_fork do |server, worker|
+      # Handle reconnection
+    end
+
+The above code should be put into a Rails initializer or similar initialization script.
 
 ## String Encoding
 
diff --git a/docs/FAQ.md b/docs/FAQ.md
index 761e270..d96b178 100644
--- a/docs/FAQ.md
+++ b/docs/FAQ.md
@@ -110,3 +110,7 @@ Without further investigation, it's impossible to know exactly what has caused t
 Because of the indeterminacy involved, the MongoDB drivers will not retry operations on connection failure. How connection failures should be handled is entirely dependent on the application. Therefore, we leave it to the application developers to make the best decision in this case.
 
 The drivers will reconnect on the subsequent operation.
+
+#### I ocassionally get an error saying that responses are out of order. What's happening?
+
+See (this JIRA issue)[http://jira.mongodb.org/browse/RUBY-221].