Template caching doesn't seem to be working anymore? #1657

Closed
Bodacious opened this Issue Jun 11, 2011 · 10 comments

Comments

Projects
None yet
4 participants
@Bodacious
Contributor

Bodacious commented Jun 11, 2011

I've upgraded my rails 3.0 app to Rails 3.1 and now I seem to be seeing a lot of log activity on pages that should be completely cached and shouldn't even touch the app.

I made a basic app tonight to test this: https://github.com/Bodacious/Rails3.1caching

The root path should be cached (and is written to the public dir) but does so on every request:

Started GET "/" for 127.0.0.1 at Sat Jun 11 20:34:38 +0100 2011
  Processing by UsersController#index as HTML
Rendered users/index.html.erb within layouts/application (0.5ms)
Write page /Users/Gavin/Sites/AssetTest/public/index.html (0.6ms)
Completed 200 OK in 5ms (Views: 2.3ms | ActiveRecord: 0.3ms)
cache: [GET /assets/application-4c93ba2b40930f2b7afa684141665b62.css] fresh
cache: [GET /assets/application-177e737147b1c56843a6eb81ac8425f9.js] fresh
cache: [GET /assets/rails.png] stale, valid, store

What's up?

@neerajdotname

This comment has been minimized.

Show comment Hide comment
@neerajdotname

neerajdotname Jun 12, 2011

Member

After the public/index.html page has been created by Rails, it is the job of webserver to render that file and not to forward the request to Rails. What webserver you are using?

Member

neerajdotname commented Jun 12, 2011

After the public/index.html page has been created by Rails, it is the job of webserver to render that file and not to forward the request to Rails. What webserver you are using?

@Bodacious

This comment has been minimized.

Show comment Hide comment
@Bodacious

Bodacious Jun 12, 2011

Contributor

I'm using NGINX

This seems to be working OK on my live production server but I'm not using the asset pipeline there.

Also, the initial index.html file that rails creates with a new app was loaded fine and the controller action was ignored. With this cached template, the controller action was called with each request.

Rails 3.1.0rc4
Ruby 1.9.2-p180

On 12 Jun 2011, at 09:28, neerajdotnamereply@reply.github.com wrote:

After the public/index.html page has been created by Rails, it is the job of webserver to render that file and not to forward the request to Rails. What webserver you are using?

Reply to this email directly or view it on GitHub:
#1657 (comment)

Contributor

Bodacious commented Jun 12, 2011

I'm using NGINX

This seems to be working OK on my live production server but I'm not using the asset pipeline there.

Also, the initial index.html file that rails creates with a new app was loaded fine and the controller action was ignored. With this cached template, the controller action was called with each request.

Rails 3.1.0rc4
Ruby 1.9.2-p180

On 12 Jun 2011, at 09:28, neerajdotnamereply@reply.github.com wrote:

After the public/index.html page has been created by Rails, it is the job of webserver to render that file and not to forward the request to Rails. What webserver you are using?

Reply to this email directly or view it on GitHub:
#1657 (comment)

@neerajdotname

This comment has been minimized.

Show comment Hide comment
@neerajdotname

neerajdotname Jun 13, 2011

Member

For me in production mode rails keep writing to public/index.html page. However in development mode it does not write the file because it loads the existing public/index.html page. I used the default webrick that comes with ruby.

I used edge rails with REE 1.8.7.

Member

neerajdotname commented Jun 13, 2011

For me in production mode rails keep writing to public/index.html page. However in development mode it does not write the file because it loads the existing public/index.html page. I used the default webrick that comes with ruby.

I used edge rails with REE 1.8.7.

@thoefer

This comment has been minimized.

Show comment Hide comment
@thoefer

thoefer Jun 13, 2011

same behavior here as described by @neerajdotname but only with ruby 1.9.2

thoefer commented Jun 13, 2011

same behavior here as described by @neerajdotname but only with ruby 1.9.2

@thoefer

This comment has been minimized.

Show comment Hide comment
@thoefer

thoefer Jun 13, 2011

In production mode Rails (more detailed: the middleware "ActionDispatch::Static") shouldn´t be responsible in serving static assets as @neerajdotname already mentioned above. Therefore the default setting in production.rb of "config.serve_static_assets = false" let´s you skip "ActionDispatch::Static" in the middleware stack. That makes absolutely sense to me. But this implies that a dedicated webserver can serve static assets. It seems to me that webrick alone simply cannot do this. When using webrick in production mode and setting "config.serve_static_assets = true" gives you the expected behavior.

thoefer commented Jun 13, 2011

In production mode Rails (more detailed: the middleware "ActionDispatch::Static") shouldn´t be responsible in serving static assets as @neerajdotname already mentioned above. Therefore the default setting in production.rb of "config.serve_static_assets = false" let´s you skip "ActionDispatch::Static" in the middleware stack. That makes absolutely sense to me. But this implies that a dedicated webserver can serve static assets. It seems to me that webrick alone simply cannot do this. When using webrick in production mode and setting "config.serve_static_assets = true" gives you the expected behavior.

@thoefer

This comment has been minimized.

Show comment Hide comment
@thoefer

thoefer Jun 13, 2011

My conclusion: When using webrick – regardless of the mode we are running in – we always should use ActionDispatch::Static in the middleware stack. Can we agree on this or am I missing something?

thoefer commented Jun 13, 2011

My conclusion: When using webrick – regardless of the mode we are running in – we always should use ActionDispatch::Static in the middleware stack. Can we agree on this or am I missing something?

@Bodacious

This comment has been minimized.

Show comment Hide comment
@Bodacious

Bodacious Jun 13, 2011

Contributor

Agree

Sent from my iPad 2

On 13 Jun 2011, at 14:03, thoeferreply@reply.github.com wrote:

My conclusion: When using webrick – regardless of the mode we are running in – we always should use ActionDispatch::Static in the middleware stack. Can we agree on this or am I missing something?

Reply to this email directly or view it on GitHub:
#1657 (comment)

Contributor

Bodacious commented Jun 13, 2011

Agree

Sent from my iPad 2

On 13 Jun 2011, at 14:03, thoeferreply@reply.github.com wrote:

My conclusion: When using webrick – regardless of the mode we are running in – we always should use ActionDispatch::Static in the middleware stack. Can we agree on this or am I missing something?

Reply to this email directly or view it on GitHub:
#1657 (comment)

@thoefer

This comment has been minimized.

Show comment Hide comment
@thoefer

thoefer Jun 14, 2011

This solutions forces Rails to include ActionDispatch::Static when in production mode and running with WEBrick. What do you think? Can you verify if this is free from unwanted side effects? One (useful IMHO) side effect is that it includes the "Server" property for the view of InfoController on Rails´s default page.

thoefer commented Jun 14, 2011

This solutions forces Rails to include ActionDispatch::Static when in production mode and running with WEBrick. What do you think? Can you verify if this is free from unwanted side effects? One (useful IMHO) side effect is that it includes the "Server" property for the view of InfoController on Rails´s default page.

@josevalim

This comment has been minimized.

Show comment Hide comment
@josevalim

josevalim Jun 14, 2011

Contributor

I don't think we should hard code specifically for the webrick handler. If you want Rails to serve the static assets in production under webrick, just set the configuration option to true.

Contributor

josevalim commented Jun 14, 2011

I don't think we should hard code specifically for the webrick handler. If you want Rails to serve the static assets in production under webrick, just set the configuration option to true.

@josevalim josevalim closed this Jun 14, 2011

@thoefer

This comment has been minimized.

Show comment Hide comment
@thoefer

thoefer Jun 14, 2011

Ok, was tinkering with myself about this. Do you think it´s necessary to document this in production.rb next to "(Apache or nginx will already do this)..."?

thoefer commented Jun 14, 2011

Ok, was tinkering with myself about this. Do you think it´s necessary to document this in production.rb next to "(Apache or nginx will already do this)..."?

jake3030 pushed a commit to jake3030/rails that referenced this issue Jun 28, 2011

Inline code comments for class_eval/module_eval [#1657 state:resolved]
Signed-off-by: Pratik Naik <pratiknaik@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment