title: Ruby on Rails loopback requests cause deadlock?
body: <p><strong>Solution</strong></p>
  
  <p>I am switching to unicorn in development mode. One worker process for each level of recursion is needed to prevent the deadlock situation, so I am running with 2 worker processes.</p>
  
  <p><strong>Problem</strong></p>
  
  <p>I am working on the <a href="http://code.macournoyer.com/thin/" rel="nofollow">Thin</a> server in my development environment. I use port 3000 (the default in dev environment). My problem is getting the server to make requests to itself.</p>
  
  <p>Let's say I have the following controller:</p>
  
  <pre><code># app/controllers/recursions_controller.rb
  class RecursionsController &lt; ApplicationController
  
      # /recursions
      def index
  
          # synchronously call recursions#show
          RestClient.get("http://localhost:3000/recursions/1") 
  
          # finish!
          render :text =&gt; 'index'
  
      end
  
      # /recursions/:id
      def show
  
          # finish immediately
          render :text =&gt; 'show'
  
      end
  
  end
  </code></pre>
  
  <p>Here is the corresponding route:</p>
  
  <pre><code># config/routes.rb
  resources :recursions
  </code></pre>
  
  <p>Here is output from the request log when I initially request <code>recursions#index</code>:</p>
  
  <pre><code>[INFO] 2013-01-15 12:09:05 -0800 Started GET "/recursions" for 127.0.0.1 at 2013-01-15 12:09:05 -0800
  Processing by RecursionsController#index as HTML
  Completed 500 Internal Server Error in 60049ms
  
  [FATAL] 2013-01-15 12:10:05 -0800 RestClient::RequestTimeout (Request Timeout):
    app/controllers/recursions_controller.rb:8:in `index'
    Rendered /usr/local/lib/ruby/gems/1.9.1/gems/actionpack-3.2.11/lib/action_dispatch/middleware/templates/rescues/_trace.erb (0.8ms)
    Rendered /usr/local/lib/ruby/gems/1.9.1/gems/actionpack-3.2.11/lib/action_dispatch/middleware/templates/rescues/_request_and_response.erb (0.7ms)
    Rendered /usr/local/lib/ruby/gems/1.9.1/gems/actionpack-3.2.11/lib/action_dispatch/middleware/templates/rescues/diagnostics.erb within rescues/layout (7.4ms)
  
  [INFO] 2013-01-15 12:10:05 -0800 
  
  [INFO] 2013-01-15 12:10:05 -0800 
  
  [INFO] 2013-01-15 12:10:05 -0800 Started GET "/recursions/1" for 127.0.0.1 at 2013-01-15 12:10:05 -0800
  Processing by RecursionsController#show as XML
    Parameters: {"id"=&gt;"1"}
    Rendered text template (0.0ms)
  Completed 200 OK in 7ms (Views: 5.5ms)
  </code></pre>
  
  <p>I suspect what is going on here is some kind of deadlock situation. Request A cannot return until request B returns (recursive ordering, can't help it), but request B cannot be processed until request A returns (apparent limitation built into my webserver?). The deadlock is resolved when RestClient times out, causing an exception and terminating request A with a 500. Only then is request B handled, though it's moot at this point.</p>
  
  <p>It seems to me like my webserver cannot handle concurrent requests. That said, here are my questions:</p>
  
  <ol>
  <li><p>Is there a webserver I can switch to in my dev environment that is not limited this way? We use Unicorn in production which can spawn multiple worker processes and therefore handle concurrent requests, but Unicorn seems too heavy for a dev environment. The same thing that makes Unicorn a solution to my problem could make it difficult to read the log output. This is my last resort solution.</p></li>
  <li><p>Is there a tricky way to make a request to the Rails/Rack frameworks that circumvents the apparent concurrent request limitation?</p></li>
  <li><p>Can anyone provide me with docs stating this limation explicitly? I don't know if it's a limitation inherent to all single-process Ruby on Rails webservers or just Thin.</p></li>
  </ol>
  
  <p><strong>Note:</strong> This is just a toy problem to demonstrate the blocking issue I am having. If you need to know the actual reason for this, it is that I am moving some HTTP services from another part of our infrastructure into our RoR app. Our RoR app consumes these service at many different points in our code, so I am trying to leave the client code for these services untouched and only change the implementation. That means making circular HTTP requests. This will be optimized at a later date, when everything has stabilized.</p>