4

rack-timeout is included in the Gemfile, but we only want it as middleware on production. Thus in an initializer, we have:

config.middleware.delete Rack::Timeout

Inspecting before and after this line shows rack-timeout removed from the array. Regardless, requests are still timing out, and a quick 'puts' in the gem shows that it is indeed the culprit.

Is this because the middleware stack has already been built before delete is called? Or is the stack read in every request? If that's the case, what could be the issue?

Peter Ehrlich
  • 6,969
  • 4
  • 49
  • 65

1 Answers1

8

Why not just have something like the following?

group :production do
  gem "rack-timeout"
end

In theory, the middleware deletion in the initializer should take care of the problem after a server restart, assuming you're talking about putting something in config/initializers/.

Did a little more experimentation and dropped this into config/initializers/rack-timeout.rb:

if Rails.env.production?
  Rack::Timeout.timeout = 0.5
else
  Rails.configuration.middleware.delete Rack::Timeout
end

And this in a scaffolded controller:

sleep 1

Everything seemed cool after I restarted the dev server (no timeouts in sight :D). So, maybe just a bad variable.

I still think using a production-only group is the better solution.

Ran with Rails 3.2.2 with ruby 1.9.2-p290 on OSX.

Joel Meador
  • 2,586
  • 2
  • 19
  • 24