中间件如何被删除?
rack-timeout 包含在 Gemfile 中,但我们只希望它作为生产中的中间件。因此,在初始化程序中,我们有:
config.middleware.delete Rack::Timeout
检查此行前后显示机架超时已从阵列中删除。不管怎样,请求仍然超时,并且快速“放入”gem 表明它确实是罪魁祸首。
这是因为在调用delete之前中间件堆栈已经构建了吗?或者每次请求时都会读取堆栈?如果是这样的话,可能是什么问题?
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?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
为什么不直接像下面这样呢?
理论上,假设您正在谈论将某些内容放入
config/initializers/
中,则初始化程序中的中间件删除应该可以在服务器重新启动后解决该问题。做了更多实验,并将其放入 config/initializers/rack-timeout.rb 中:
这在脚手架控制器中:
在我重新启动开发服务器后,一切看起来都很酷(看不到超时:D) 。所以,也许只是一个坏变量。
我仍然认为使用仅生产组是更好的解决方案。
在 OSX 上使用 Rails 3.2.2 和 ruby 1.9.2-p290 运行。
Why not just have something like the following?
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
:And this in a scaffolded controller:
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.