Remove the word "mongrel" from documents

Currently mongrel is not maintained.
And it couldn't be built with any Ruby versions that
supported by Rails.

It is reasonable to remove the word "mongrel" in order to avoid
confusion from newcomer.

4 files changed, 4 insertions, 4 deletions

diff --git a/guides/source/caching_with_rails.md b/guides/source/caching_with_rails.md
index a1b0029c47..fd7626250c 100644
--- a/guides/source/caching_with_rails.md
+++ b/guides/source/caching_with_rails.md
@@ -381,7 +381,7 @@ config.cache_store = :memory_store, { size: 64.megabytes }
 ```
 
 If you're running multiple Ruby on Rails server processes (which is the case
-if you're using mongrel_cluster or Phusion Passenger), then your Rails server
+if you're using Phusion Passenger or puma clustered mode), then your Rails server
 process instances won't be able to share cache data with each other. This cache
 store is not appropriate for large application deployments. However, it can
 work well for small, low traffic sites with only a couple of server processes,
diff --git a/guides/source/configuring.md b/guides/source/configuring.md
index a115683134..c54affb70e 100644
--- a/guides/source/configuring.md
+++ b/guides/source/configuring.md
@@ -1198,7 +1198,7 @@ development:
   timeout: 5000
 ```
 
-Since the connection pooling is handled inside of Active Record by default, all application servers (Thin, mongrel, Unicorn etc.) should behave the same. The database connection pool is initially empty. As demand for connections increases it will create them until it reaches the connection pool limit.
+Since the connection pooling is handled inside of Active Record by default, all application servers (Thin, Puma, Unicorn etc.) should behave the same. The database connection pool is initially empty. As demand for connections increases it will create them until it reaches the connection pool limit.
 
 Any one request will check out a connection the first time it requires access to the database. At the end of the request it will check the connection back in. This means that the additional connection slot will be available again for the next request in the queue.
 
diff --git a/guides/source/initialization.md b/guides/source/initialization.md
index a2eec03eba..054b845faa 100644
--- a/guides/source/initialization.md
+++ b/guides/source/initialization.md
@@ -318,7 +318,7 @@ def parse!(args)
   args, options = args.dup, {}
 
   opt_parser = OptionParser.new do |opts|
-    opts.banner = "Usage: rails server [mongrel, thin, etc] [options]"
+    opts.banner = "Usage: rails server [puma, thin, etc] [options]"
     opts.on("-p", "--port=port", Integer,
             "Runs Rails on the specified port.", "Default: 3000") { |v| options[:Port] = v }
   ...
diff --git a/guides/source/security.md b/guides/source/security.md
index 5c3d465220..aea9728c10 100644
--- a/guides/source/security.md
+++ b/guides/source/security.md
@@ -131,7 +131,7 @@ It works like this:
 * The user takes the cookie from the first step (which they previously copied) and replaces the current cookie in the browser.
 * The user has their original credit back.
 
-Including a nonce (a random value) in the session solves replay attacks. A nonce is valid only once, and the server has to keep track of all the valid nonces. It gets even more complicated if you have several application servers (mongrels). Storing nonces in a database table would defeat the entire purpose of CookieStore (avoiding accessing the database).
+Including a nonce (a random value) in the session solves replay attacks. A nonce is valid only once, and the server has to keep track of all the valid nonces. It gets even more complicated if you have several application servers. Storing nonces in a database table would defeat the entire purpose of CookieStore (avoiding accessing the database).
 
 The best _solution against it is not to store this kind of data in a session, but in the database_. In this case store the credit in the database and the logged_in_user_id in the session.